MELJUN CORTES Analysis concepts and principles

301 views
229 views

Published on

MELJUN CORTES Analysis concepts and principles----->THESIS writing model techniques on how to prepare DFD.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
301
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

MELJUN CORTES Analysis concepts and principles

  1. 1. Requirements Analysis Analysis as a bridge between system engineering and software design MELJUN CORTES
  2. 2. Analysis Concepts and Principles Requirements Elicitation
  3. 3. Requirements Elicitation Before requirements can be analyzed, modeled, or specified they must be gathered through an elicitation process. A customer has a problem that may be amenable to a computer-based solution. A developer responds to the customer's request for help. Communication has begun.
  4. 4. Requirements Elicitation Initiating The Process
  5. 5. Initiating the Process The most commonly used requirements elicitation technique is to conduct a meeting or interview. ◦ Analyst should first start by asking context-free questions. That is, a set of questions that will lead to a basic understanding of the problem, the people who want a solution, the nature of the solution that is desired, and the effectiveness of the first encounter itself. (Gause and Weinberg)
  6. 6. Initiating the Process The first set of context-free questions focuses on the customer, the overall goals, and the benefits.
  7. 7. Initiating the Process The next set of questions enables the analyst to gain a better understanding of the problem and the customer to voice his or her perceptions about a solution.
  8. 8. Initiating the Process The final set of questions focuses on the effectiveness of the meeting. ◦ Meta-questions. (Gause and Weinberg)
  9. 9. Requirements Elicitation Facilitated Application Specification Techniques
  10. 10. Facilitated Application Specification Techniques A number of independent investigators have developed a team-oriented approach to requirements gathering that is applied during early stages of analysis and specification.
  11. 11. Facilitated Application Specification Techniques Facilitated Application Specification Techniques (FAST), this approach encourages the creation of a joint team of customers and developers who work together to identify the problem, propose elements of the solution, negotiate different approaches and specify a preliminary set of solution requirements
  12. 12. Facilitated Application Specification Techniques Basic Guidelines
  13. 13. Basic Guidelines Arrange a meeting at a neutral site for developers and customers. Establishment of rules for preparation and participation. Prepare and informal agenda that encourages free flow of ideas.
  14. 14. Basic Guidelines Appoint a facilitator – can be a customer, a developer, or an outside expert – to control the meeting. Prepare a definition mechanism – Board, Flip Charts, Worksheets, Wall Stickers, Etc. Participants should not criticize or debate.
  15. 15. Facilitated Application Specification Techniques Activities Of FAST Session
  16. 16. Activities of FAST Session Each participants presents their list of objects, services, constraints, and performance for discussion. List may be displayed in the meeting using board, or any other mechanism, so that it will be visible to all the participants.
  17. 17. Activities of FAST Session The combined list for each topic are prepared by eliminating redundant entries and adding new ideas. The combined lists are again discussed and consensus lists are finalized by the facilitator.
  18. 18. Activities of FAST Session Once the consensus lists have been completed, the team is divided into smaller sub teams, each works to develop mini-specifications for one or more entries of the lists.
  19. 19. Activities of FAST Session Each sub team then presents minispecification to all FAST attendees. After discussion, additions or deletions are made to the lists. We may get new objects, services, constraints, or performance requirements to be added to original lists.
  20. 20. Activities of FAST Session During all discussion, the team may raise an issue that cannot be resolved during the meeting. An issue list is prepared so that these ideas will be considered later.
  21. 21. Activities of FAST Session Each attendee prepares a list of validation criteria for the product/system and presents the list to the team. A consensus list of validation criteria is then created. A sub team may be asked to write the complete draft specifications using all inputs from the FAST meeting.
  22. 22. Requirements Elicitation Quality Function Deployment
  23. 23. Quality Function Deployment Quality function deployment (QFD) is a quality management technique that translates the needs of the customer into technical requirements for software. QFD “concentrates on maximizing customer satisfaction from the software engineering process.” To accomplish this, QFD emphasizes an understanding of what is valuable to the customer and then deploys these values throughout the engineering process.
  24. 24. Quality Function Deployment Quality Function Deployment Types Of Requirements
  25. 25. QFD Types of Requirements Normal Requirements ◦ The objectives and goals that are stated for a product or system during meetings with the customer. If these requirements are present, the customer is satisfied.
  26. 26. QFD Types of Requirements Expected Requirements ◦ These requirements are implicit to the product or system and may be so fundamental that the customer does not explicitly state them. Their absence will be a cause for significant dissatisfaction.
  27. 27. QFD Types of Requirements Exciting Requirements ◦ These features go beyond the customer’s expectations and prove to be very satisfying when present. For example, word processing software is requested with standard features. The delivered product contains a number of page layout capabilities that are quite pleasing and unexpected.
  28. 28. Requirements Elicitation Use - Cases
  29. 29. Use-Case Use cases are a software modeling technique that helps developers to determine which features to implement and how to resolve errors gracefully.
  30. 30. Use-Case To create a use-case ◦ The analyst must first identify the different types of people (or devices) that use the system or product. ◦ Create a user profile for each category of users, including all the roles the users play.
  31. 31. Use-Case To create a use-case ◦ Create a use-case for each goal – following the usecase template. ◦ Structure the use-cases. Avoid over-structuring. ◦ Review and validate with users.
  32. 32. Use-Case Use - Case Template 1 Brief Description 2 Actors 3 Pre - condition 4 Post - condition 5 Flow of Events 6 Special Requirements 7 Related Use Cases
  33. 33. Use-Case Use - Case Template 1 Brief Description 2 Actors 3 Pre - condition 4 Post - condition 5 Flow of Events 6 Special Requirements 7 Related Use Cases Actors ◦ Represent roles that people (or devices) play as the system operates. ◦ Also anything that communicates with the system or product and that is external to the system itself.
  34. 34. Use-Case Use - Case Template 1 Brief Description 2 Actors 3 Pre - condition 4 Post - condition 5 Flow of Events 6 Special Requirements 7 Related Use Cases Flow of Events ◦ Basic Flow ◦ Alternative Flow
  35. 35. Use-Case Restaurant Use Case Model
  36. 36. Analysis Concepts and Principles Analysis Principles
  37. 37. Analysis Principles The Information domain of a problem must be represented and understood. The functions that the software is to perform must be defined. The behavior of the software must be represented.
  38. 38. Analysis Principles The models that depict information, function and behavior must be partitioned in a manner that uncovers detail in a layered fashion. The analysis process should move from essential information toward implementation details.
  39. 39. Analysis Principles Information Domain
  40. 40. Information Domain The information domain contains three different views of the data and control. ◦ Information content and relationships.
  41. 41. Information Domain The information domain contains three different views of the data and control. ◦ Information content and relationships. ◦ Information flow.
  42. 42. Information Domain Information Flow
  43. 43. Information Domain The information domain contains three different views of the data and control. ◦ Information content and relationships. ◦ Information flow. ◦ Information structure.
  44. 44. Analysis Principles Modeling
  45. 45. Modeling Physical (a building, a plane, a machine) ◦ We can build a model that is identical in form and shape but smaller in scale. Software ◦ It must be capable of representing the information that software transforms, the functions (and sub functions) that enable the transformation to occur, and the behavior of the system as the transformation is taking place.
  46. 46. Modeling Types Of Modeling
  47. 47. Types of Modeling Functional Models ◦ Software transforms information, and in order to accomplish this, it must perform at least three generic functions: input, processing, and output.
  48. 48. Types of Modeling Behavioral Models ◦ Most software responds to events from the outside world. This stimulus/response characteristic forms the basis of the behavioral model.
  49. 49. Analysis Principles Partitioning
  50. 50. Partitioning Problems are often too large and complex to be understood as a whole. For this reason, partitioning (dividing) such problems into parts that can be easily understood and establish interfaces between the parts so that overall function can be accomplished.
  51. 51. Partitioning SafeHome Software Exposing hierarchy increasing detail by moving vertically in the
  52. 52. Partitioning SafeHome Software Configure System Exposing hierarchy increasing detail by moving vertically in the
  53. 53. Partitioning SafeHome Software Configure System Exposing hierarchy Monitor Sensors increasing detail by moving vertically in the
  54. 54. Partitioning SafeHome Software Configure System Exposing hierarchy Monitor Sensors increasing detail by moving vertically in the
  55. 55. Partitioning SafeHome Software Configure System Monitor Sensors Poll for Sensor Event Exposing hierarchy increasing detail by moving vertically in the
  56. 56. Partitioning SafeHome Software Configure System Monitor Sensors Poll for Sensor Event Exposing hierarchy Activate Alarm Function increasing detail by moving vertically in the
  57. 57. Partitioning SafeHome Software Configure System Monitor Sensors Poll for Sensor Event Exposing hierarchy Interact With User Activate Alarm Function increasing detail by moving vertically in the
  58. 58. Partitioning SafeHome Software Functionally decomposing the problem by moving horizontally in the hierarchy.
  59. 59. Partitioning SafeHome Software Configure System Functionally decomposing the problem by moving horizontally in the hierarchy.
  60. 60. Partitioning SafeHome Software Configure System Functionally Monitor Sensors decomposing the problem by moving horizontally in the hierarchy.
  61. 61. Partitioning SafeHome Software Configure System Functionally Monitor Sensors Interact with User decomposing the problem by moving horizontally in the hierarchy.
  62. 62. Partitioning SafeHome Software Configure System Monitor Sensors Interact with User Poll for Sensor Event Functionally decomposing the problem by moving horizontally in the hierarchy.
  63. 63. Partitioning SafeHome Software Configure System Monitor Sensors Poll for Sensor Event Functionally Interact with User Activate Alarm Function decomposing the problem by moving horizontally in the hierarchy.
  64. 64. Analysis Concepts and Principles Essential View
  65. 65. Essential View Logical
  66. 66. Analysis Concepts and Principles Implementation View
  67. 67. Implementation View Physical
  68. 68. Analysis Concepts and Principles Software Prototyping
  69. 69. Software Prototyping Prototyping is the rapid development of a system. Rapid software development to validate requirements.
  70. 70. Software Prototyping The principal use is to help customers and developers understand the requirements for the system. ◦ Requirements elicitation – Users can experiment with a prototype to see how the system supports their work. ◦ Requirements validation – The prototype can reveal errors and omissions in the requirements.
  71. 71. Software Prototyping Prototyping Approach
  72. 72. Prototyping Approach The prototyping paradigm can be either closeended or open-ended. ◦ The close-ended approach is often called throwaway prototyping. Using this approach, a prototype serves solely as a rough demonstration of requirements. It is then discarded, and the software is engineered using a different paradigm.
  73. 73. Prototyping Approach The prototyping paradigm can be either closeended or open-ended. ◦ An open-ended approach, called evolutionary prototyping, uses the prototype as the first part of an analysis activity that will be continued into design and construction.
  74. 74. Software Prototyping Prototyping Methods And Tools
  75. 75. Prototyping Methods and Tools Fourth Generation Techniques ◦ 4GT encompass a broad array of database query and reporting languagfes, program and application generators, and other very high-level nonprocedural languages. Because 4GT enable the software engineer to generate executable code quickly, they are ideal for rapid prototyping.
  76. 76. Prototyping Methods and Tools Reusable Software Components ◦ Another approach to rapid prototyping is to assemble, rather than build, the prototype by using a set of existing software components. It should be noted that an existing software product can be used as a prototype for a "new, improved" competitive product. In a way, this is a form of reusability for software prototyping.
  77. 77. Prototyping Methods and Tools Formal Specification and Prototyping Environments ◦ Over the past two decades, a number of formal specification languages and tools have been developed as a replacement for natural language specification techniques.
  78. 78. Prototyping Methods and Tools Formal Specification and Prototyping Environments ◦ Today, developers of the formal languages are in the process of developing interactive environments that  Enable an analyst to interactively create language-based specifications of a system or software,  Invoke automated tools that translate the language-based specifications into executable code, and  Enable the customer to use the prototype executable code to refine fomral requirements.
  79. 79. Specification Specification Principles
  80. 80. Specification Principles Separate functionality from implementation. Develop a model of the desired behavior of a system. Establish operates. Define the background in which software the environment established.
  81. 81. Specification Principles Create a cognitive model rather than a design or implementation model. Recognize that “the specifications must be tolerant of incompleteness and augmentable.” A specification is always a model—an abstraction—of some real (or envisioned) situation that is normally quite complex. Hence, it will be incomplete and will exist at many levels of detail. Establish the content and structure of a specification in a way that will enable it to be amenable to change.
  82. 82. Analysis Concepts and Principles Specification Review
  83. 83. Specification Review review of the Software Requirements Specification (and/or prototype) is conducted by both the software developer and the customer. Because the specification forms the foundation of the development phase, extreme care should be taken in conducting the review. A

×