1. 1 Chapter 11 Analysis Concepts and Principles

2. 2 Requirements Analysis

3. 3  Result in the specification of software’s operational characteristics  Indicate software’s interface with other system elements  Establish constraints that software must meet

4. 4 Requirements Analysis  Analyst – to refine the software allocation and build models of the data, functional, and behavioral domains that will be treated by software.  Designer – provide a representation of information, function, and behavior that can be translated to data, architectural, interface, and component-level designs.  Developer and customer – to assess quality once software is built.

5. 5 Requirements Analysis  Five areas of effort Problem recognitionProblem recognition Evaluation and solution synthesisEvaluation and solution synthesis ModelingModeling SpecificationSpecification ReviewReview

6. 6 The Analysis Process the problem 1.requirementselicitation 3. build a prototype 2.createanalysismodels 4. develop Specification 5.Review

7. 7 1. Requirements Elicitation Context-Free Questions  Focuses on the customer, the overall goals, and benefits: Who is behind the request for this work?Who is behind the request for this work? Who will use the solution?Who will use the solution? What will be the economic benefit of a successful solution?What will be the economic benefit of a successful solution? Is there another source for the solution that you need?Is there another source for the solution that you need?

8. 8  Enable the analyst to gain a better understanding of the problem and the customer to voice his or her perceptions about a solution: How would you characterize “good output that would be generated by a successful solution?How would you characterize “good output that would be generated by a successful solution? What problem(s) will this solution address?What problem(s) will this solution address? Can you show me the environment in which the solution will be used?Can you show me the environment in which the solution will be used? Will special performance issues or constraints affect the way the solution is approached?Will special performance issues or constraints affect the way the solution is approached?

9. 9  Focuses on the effectiveness of the meeting: Are you the right person to answer these questions? Are your answers “official”?Are you the right person to answer these questions? Are your answers “official”? Are my questions relevant to the problem that you have?Are my questions relevant to the problem that you have? Am I asking too many questions?Am I asking too many questions? Can anyone else provide additional information?Can anyone else provide additional information? Should I be asking you anything else?Should I be asking you anything else?

10. 10 Facilitated Application Specification Techniques (FAST)  A meeting is conducted at a neutral site and attended by both software engineers and customers.  Rules for preparation and participation are established.  An agenda is suggested that is formal enough to cover all important points but informal enough to encourage the free flow of ideas.  A “facilitator” controls the meeting.  A “definition mechanism” is used  ….

11. 11 Quantity Function Deployment (QFD)  QFD is a quality management technique that translates the needs of the customer into technical requirements for software.  Three types of requirements Normal requirementNormal requirement Expected requirementExpected requirement Exciting requirementExciting requirement

12. 12 Use-Cases  A collection of scenarios that describe the thread of usage of a system  Each scenario is described from the point-of-view of an “actor”—a person or device that interacts with the software in some way  Each scenario answers the following questions: What are the main tasks of functions performed by the actor?What are the main tasks of functions performed by the actor? What system information will the actor acquire, produce or change?What system information will the actor acquire, produce or change? Will the actor inform the system about environmental changes?Will the actor inform the system about environmental changes? What information does the actor require of the system?What information does the actor require of the system? Does the actor wish to be informed about unexpected changesDoes the actor wish to be informed about unexpected changes

13. 13 2. Analysis Model Data Model Behavioral Model Functional Model

14. 14 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.  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 detail.

15. 15 Analysis Guiding Principle  Understand the problem before you begin to create the analysis model.  Develop prototypes that enable a user to understand how human/machine interaction will occur.  Record the origin of and the reason for ever requirement.  Use multiple views of requirements.  Rank requirements.  Work to eliminate ambiguity. Davis

16. 16 Analysis Principle I Model the Data Domain  define data objects  describe data attributes  establish data relationships

17. 17

18. 18 Analysis Principle II Model Function  identify functions that transform data objects  indicate how data flow through the system  represent producers and consumers of data

19. 19 Analysis Principle III Model Behavior  indicate different states of the system  specify events that cause the system to change state

20. 20 Analysis Principle IV Partition the Models  refine each model to represent lower levels of abstraction refine data objects refine data objects create a functional hierarchy create a functional hierarchy represent behavior at different levels of detail represent behavior at different levels of detail

21. 21 Partitioning  Horizontally moving – decomposing problem  Vertically moving – increasing detail

22. 22

23. 23 Analysis Principle V Essence & Implementation Views  Essential view – the functions and information  Implementation view – real world manifestation of processing function and information structures

24. 24 3. Software Prototyping  Candidacy factors Application areaApplication area Application complexityApplication complexity Customer characteristicsCustomer characteristics Project characteristicsProject characteristics  Types close-ended (throwaway prototyping)close-ended (throwaway prototyping) open-ended (evolutionary prototyping) open-ended (evolutionary prototyping)  Methods Fourth generation techniquesFourth generation techniques Reusable software componentsReusable software components Formal specification and prototyping environmentsFormal specification and prototyping environments

25. 25

26. 26 4. Software Requirements Specification

27. 27 Specification Principles  Separate functionality from implementation  Develop a desired behavior model of a system  Establish the context  Define the environment  Create a cognitive model  Recognize incompleteness and augmentable  Establish a changeable content and structure

28. 28 Representation  Representation format and content should be relevant to the problem.  Information contained within the specification should be nested.  Diagrams and other notational forms should be restricted in number and consistent in use.  Representations should be revisable.

29. 29 5. Specification Review  Ensure complete, consistent, and accurate  Not only broad descriptions, but worded  Contract  Change – increase cost  Difficult to test – inconsistency and omissions

30. 30Modeling  Modeling Data modelsData models Functional modelsFunctional models Behavioral modelsBehavioral models  Advantages Aid the analyst in understanding the information, function, and behavior of a system.Aid the analyst in understanding the information, function, and behavior of a system. Become the focal point for review and the key to a determination of completeness, consistency, and accuracy of the specifications.Become the focal point for review and the key to a determination of completeness, consistency, and accuracy of the specifications. Becomes the foundation for design. Provide an essential representation of software that can be “mapped” into an implementation context.Becomes the foundation for design. Provide an essential representation of software that can be “mapped” into an implementation context.