Software Engineering

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

2. Objectives • Motivate for analysis • Introduce the general analysis process • Requirements elicitation • Developing prototypes • Creating Analysis Models • Producing a Requirements Specification • Identify key principles that are applied to analysis

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

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

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

6. build a prototype Requirements Elicitation require. elicitation develop spec. Review analysis models • Communicate with the customer(s) to elicit the requirements of the system • Informal approach - meetings and interviews • Ask 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?” • BUT really only good for the initial meeting • Problem: customers communicate wants not needs • Other structured approaches: FAST, QFD, Use-Cases, questionnaires, hidden cameras!

7. Facilitated Application Specification Techniques (FAST) • Overcome the “us and them” mindset of developers and customers • Create 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 Customer Engineering Group Group

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

9. Quality Function Deployment • Quality management technique that ranks customer requirements as: • Normal requirements – if these are present the customer is satisfied • Expected requirements – often implicit, absence will cause much “wailing and gnashing of teeth” • Exciting requirements – above and beyond the user’s expectations • Components: • 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 • 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” • “Role” is a better word • A person or device that interacts with the software in some way • Each 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? • Method adopted in this course

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

12. Pros and Cons of Prototyping • Warning 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) • Case Studies Report: • Enthusiastic reception from users • Improved usability of final software • 2/3 of the study didn’t discard the prototype • Prototyping might lead to unfortunate user expectations about change • The prototype can be retained as long as it undergoes rigorous design and quality assurance. But this defeats the purpose of prototyping

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

14. Analysis Principles • Focus on the essence of the problem (no implementation details) • Examine “what” rather than “how” • 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 every requirement • Use multiple views of requirements • Prioritize requirements • Work to eliminate ambiguity (primary advantage of Formal Mathematical Specification)

15. Procedural Models • Data: • define data objects, attributes and relationships • traditionally use Entity Relationship diagrams • Function: • 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 • Behaviour: • 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 • Problems are often too large and complex to be understood as a whole • Create a hierarchical representation of the requirements • refine each model to represent lower levels of abstraction • refine data objects • create a functional hierarchy • represent behavior at different levels of detail

17. build a prototype Requirements Spec. require. elicitation develop spec. Review analysis models • End product of analysis • The requirements specification is the official statement of what is required of the system developers • Should include both a definition and a specification of requirements • It 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

18. Users of the Requirements Spec. Specify the requirements and read them to check that they meet their needs. They specify changes to the requirements. System Customers Use the requirements document to plan a bid for the system and to plan the system development process Managers Use the requirements to understand what system is to be developed System Engineers System Test 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 System Maintenance Engineers

19. Properties of the Spec • Separate functionality from implementation • Specify external system behaviour • Specify implementation constraints • Be easy to change • Serve as reference tool for maintenance • Record forethought about the life cycle of the system • Characterise responses to unexpected events • Recognize that “the specification must be tolerant of incompleteness and augmentation”

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

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