Software Engineering

1. Software Engineering Analysis (Concepts and Principles)

2. Objectives • To introduce the general analysis process • To identify key principles that are applied to analysis

3. What Are the Real Problems? • 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” • The customer keeps changing requirements • The developer is “racheted” by these changes, making errors in specifications and development • And so it goes…

4. Software Requirements Analysis • identify the “customer” and work together to negotiate “product-level” requirements • build an analysis model • focus on data • define function • represent behavior • prototype areas of uncertainty • develop a specification that will guide design • conduct formal technical reviews • A bridge between system engineering and software design.

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 elicite the requirements of the system • Informal approach: meetings and interviews • Ask questions: • Context free: “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 • Other structured approaches: FAST, QFD, Use-Cases • “He who asks a question is a fool for five minutes; he who does not ask a question remains a fool forever”

7. Facilitated Application Specification Techniques • 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 J. Wood & D. Silver

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”—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 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 the SE project

11. build a prototype Prototypes require. elicitation develop spec. Review analysis models • If the requirements are uncertain then prototyping during analysis may be appropriate • Can use throwaway or evolutionary prototyping • Selecting an approach:

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

13. Analysis Principles • begin by focusing on the essence of the problem without regard to 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)

14. 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

15. Partitioning the 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

16. 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 of WHAT the system should do rather than HOW it should do it

17. 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

18. 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 i.e. predict changes • Characterise responses to unexpected events • Recognize that “the specification must be tolerant of incompleteness and augmentation”

19. 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

20. 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