Software Engineering Analysis Concepts and Principles Objectives l

Software Engineering Analysis (Concepts and Principles)

Objectives l To introduce the general analysis process l To identify key principles that are applied to analysis

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

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

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

build a prototype require. elicitation develop spec. analysis models Review Requirements Elicitation l Communicate with the customer(s) to elicite the requirements of the system l Informal approach: meetings and interviews l 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? ” l But really only good for the initial meeting l Other structured approaches: FAST, QFD, Use-Cases l “He who asks a question is a fool for five minutes; he who does not ask a question remains a fool forever”

Facilitated Application Specification Techniques l Overcome the “us and them” mindset of developers and customers Software Engineering Group l Create a joint team customers and that work Customer Group of developers together to: - Identify the problem - Propose elements of the solution - Negotiate different approaches - Specify a preliminary set of solution requirements

FAST Guidelines l Meetings have a specific structure: - Rules for preparation and participation - A “facilitator” and “definition mechanism” l Predominantly used in IS community implemented as Joint Application Development (JAD) l 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 J. Wood & D. Silver don’t get mired in technical detail

Quality Function Deployment l Quality 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 l 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

Use-Cases l A collection of scenarios that describe thread of usage of a system l Each scenario is described from the point-of-view of an “actor”—a person or device that interacts with the software in some way l 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? l Method adopted in the SE project

build a prototype require. elicitation develop spec. Prototypes Review analysis models l If the requirements are uncertain then prototyping during analysis may be appropriate l Can use throwaway or evolutionary prototyping l Selecting an approach: Question Throwaway Evolutionary Further Work Is the application domain understood? Yes No Can the problem be modeled? Yes No Is the customer certain of the basic system? Yes/No No Are the requirement established and stable? No Yes Are any requirements ambiguous? Yes No Yes Are there contradictions in the requirements? Yes No Yes

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

Analysis Principles l begin by focusing on the essence of the problem without regard to implementation details l Examine “What” rather than “how” l Understand the problem before you begin to create the analysis model. l Develop prototypes that enable a user to understand how human-machine interaction will occur. l Record the origin of and the reason for every requirement. l Use multiple views of requirements. l Prioritize requirements. l Work to eliminate ambiguity. (Primary advantage of Formal Mathematical Specification)

Models l Data: - define data objects, attributes and relationships - Traditionally use Entity Relationship diagrams l 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 l Behaviour: - indicate different states of the system - specify events that cause the system to change state - traditionally use State Transition Diagrams

Partitioning the Models l Problems are often too large and complex to be understood as a whole l Create a hierarchical representation of the requirements l refine each model to represent lower levels of abstraction - refine data objects - create a functional hierarchy - represent behavior at different levels of detail

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

Users of the Requirements Spec. System Customers Managers Specify the requirements and read them to check that they meet their needs. They specify changes to the requirements. 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 Use the requirements to develop validation tests for the system System Maintenance Engineers Use the requirements to help understand the system and the relationship between its parts

Properties of the Spec l l l 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 l Characterise responses to unexpected events l Recognize that “the specification must be tolerant of incompleteness and augmentation”

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

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