1. Software Engineering Analysis (Concepts and Principles) James Gain (jgain@cs.uct.ac.za)jgain@cs.uct.ac.za http://people.cs.uct.ac.za/~jgain

2. Objectives lMotivate for analysis lIntroduce the general analysis process  Requirements elicitation  Developing prototypes  Creating Analysis Models  Producing a Requirements Specification lIdentify key principles that are applied to analysis

3. No Formal Customer Requirements lRecipe for disaster: 1.The customer has only a vague idea of what is required 2.The developer is willing to proceed with the “vague idea” on the assumption that “we’ll fill in the details as we go” 3.Repeat a.Customer keeps changing requirements b.Developer is “ratcheted” by these changes, making errors in specifications and development Until the project flops

4. Software Requirements Analysis lIdentify the “customer” and work together to negotiate “product-level” requirements lBuild an analysis model (warning: not object-oriented)  focus on data  define function  represent behavior lPrototype areas of uncertainty lDevelop a specification (semi-formal contract between customer and developers) that will guide design lConduct formal technical reviews

5. The Analysis Process the problem requirements elicitation build a prototype create analysis models develop Specification Review

6. Requirements Elicitation lCommunicate with the customer(s) to elicit the requirements of the system lInformal approach - meetings and interviews lAsk questions:  Context: “who is behind the request for this work?”, “who will use the solution?”, “Is there another source for the solution?”  Specific: “What problems will this solution address?”, “What are the performance issues or constraints?”  Meta-questions: “Are you the right person to answer these questions?”, “Should I be asking you anything else?” lBUT really only good for the initial meeting lProblem: customers communicate wants not needs lOther structured approaches: FAST, QFD, Use-Cases, questionnaires, hidden cameras! require. elicitation build a prototype analysis models develop spec. Review

7. Facilitated Application Specification Techniques (FAST) lOvercome the “us and them” mindset of developers and customers lCreate a joint team of customers and developers that work together to:  Identify the problem  Propose elements of the solution  Negotiate different approaches  Specify a preliminary set of solution requirements Software Engineering Group Customer Group

8. FAST Guidelines lMeetings have a specific structure:  Rules for preparation and participation  A “facilitator” and “definition mechanism” lPredominantly used in IS community - implemented as Joint Application Development (JAD) lRules: 1.participants must attend the entire meeting 2.all participants are equal 3.preparation is as important as meeting 4.all pre-meeting documents are to be viewed as “proposed” 5.off-site meeting location is preferred 6.set an agenda and maintain it 7.don’t get mired in technical detail

9. Quality Function Deployment lQuality management technique that ranks customer requirements as: 1.Normal requirements – if these are present the customer is satisfied 2.Expected requirements – often implicit, absence will cause much “wailing and gnashing of teeth” 3.Exciting requirements – above and beyond the user’s expectations lComponents:  Function deployment determines the “value” (as perceived by the customer) of each function required of the system  Information deployment identifies data objects and events  Task deployment examines the behavior of the system  Value analysis determines the relative ranking of requirements

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

11. Prototypes lIf the requirements are uncertain then consider prototyping during analysis lBuild a prototype  Show it to the customers  Adapt it to their needs lFeatures:  Rapid (gloss over imperfections, ignore design issues)  Built for change (will have to undergo quick iterations)  Throwaway (must not live beyond requirements phase) lInvaluable for mock-ups of the user interface require. elicitation build a prototype analysis models develop spec. Review

12. Pros and Cons of Prototyping lWarning label:  Do not use the prototype as the legal specification document  Do not develop the prototype into the product (good to code it in a different language from the main development) lCase Studies Report: 3Enthusiastic reception from users 3Improved usability of final software 72/3 of the study didn’t discard the prototype lPrototyping might lead to unfortunate user expectations about change lThe prototype can be retained as long as it undergoes rigorous design and quality assurance. But this defeats the purpose of prototyping

13. Create Analysis Models require. elicitation build a prototype analysis models develop spec. Review Data Model Behavioral Model Functional Model

14. Analysis Principles lFocus on the essence of the problem (no implementation details) lExamine “what” rather than “how” lUnderstand the problem before you begin to create the analysis model lDevelop prototypes that enable a user to understand how human-machine interaction will occur lRecord the origin of and the reason for every requirement lUse multiple views of requirements lPrioritize requirements lWork to eliminate ambiguity (primary advantage of Formal Mathematical Specification)

15. Procedural Models Procedural Models lData:  define data objects, attributes and relationships  traditionally use Entity Relationship diagrams lFunction:  identify functions that transform data objects  indicate how data flows through the system  represent producers and consumers of data  traditionally use Data and Control Flow Diagrams lBehaviour:  indicate different states of the system  specify events that cause the system to change state  traditionally use State Transition Diagrams

16. Partitioning the Procedural Models lProblems are often too large and complex to be understood as a whole lCreate a hierarchical representation of the requirements lrefine each model to represent lower levels of abstraction  refine data objects  create a functional hierarchy  represent behavior at different levels of detail

17. Requirements Spec. lEnd product of analysis lThe requirements specification is the official statement of what is required of the system developers lShould include both a definition and a specification of requirements lIt is NOT a design document. As far as possible, it should set out WHAT the system should do rather than HOW it should do it require. elicitation build a prototype analysis models develop spec. Review

18. Users of the Requirements Spec. System Customers Specify the requirements and read them to check that they meet their needs. They specify changes to the requirements. Managers Use the requirements document to plan a bid for the system and to plan the system development process System Engineers Use the requirements to understand what system is to be developed System Test Engineers System Maintenance Engineers Use the requirements to develop validation tests for the system Use the requirements to help understand the system and the relationship between its parts

19. Properties of the Spec lSeparate functionality from implementation lSpecify external system behaviour lSpecify implementation constraints lBe easy to change lServe as reference tool for maintenance lRecord forethought about the life cycle of the system lCharacterise responses to unexpected events lRecognize that “the specification must be tolerant of incompleteness and augmentation”

20. Spec Structure lIntroduction – set out goals, objectives and context of the software lInformation Description – document data content, flow and structure lFunctional Description – A description of the functions required to solve the problem lBehavioural Description – operation of the software as a result of internal and external events lValidation Criteria – often overlooked, how is a successful implementation going to be recognized lBibliography and Appendix – reference to related documents, definition of terms, graphical models

21. Requirements Review lThis is conducted by both customers and developers lOnce complete the Software Requirements Specification document is “signed off” by the customer and developer lBut Spec is difficult to test in a meaningful way require. elicitation build a prototype analysis models develop spec. Review