Requirements Engineering: Analysis and Management

1. Unit 2 REQUIREMENT ANALYSIS By Swati Kawathekar

2. Introduction • The broad spectrum of tasks and techniques that lead to an understanding of requirements is called requirements engineering. • Requirements engineering provides the appropriate mechanism for understanding what the customer wants, analyzing need, assessing feasibility, negotiating a reasonable solution, specifying the solution unambiguously, validating the specification, and managing the requirements as they are transformed into an operational system. • It encompasses seven distinct tasks: inception, elicitation, elaboration, negotiation, specification, validation, and management

3. Requirements Engineering-I • Inception—ask a set of questions that establish … • basic understanding of the problem • the people who want a solution • the nature of the solution that is desired, and • the effectiveness of preliminary communication and collaboration between the customer and the developer • Elicitation—elicit requirements from all stakeholders • Problems of scope – ill-defined boundary • Problems of understanding • Problems of volatility- requirements changes over time • Elaboration—create an analysis model that identifies data, function and behavioral requirements • Negotiation—agree on a deliverable system that is realistic for developers and customers

4. Requirements Engineering-II • Specification—can be any one (or more) of the following: • A written document • A set of models • A formal mathematical • A collection of user scenarios (use-cases) • A prototype • Validation—a review mechanism that looks for • errors in content or interpretation • areas where clarification may be required • missing information • inconsistencies (a major problem when large products or systems are engineered) • conflicting or unrealistic (unachievable) requirements. • Requirements management • Set of activities help the project team to identify, control and track requirements and change requirements at any time as the project proceeds

5. Establishing the Groundwork • Identify stakeholders • “whom else do you think I should talk to?” • Recognize multiple viewpoints • Work toward collaboration • The first questions • Who is behind the request for this work? • Who will use the solution? • What will be the economic benefit of a successful solution • Is there another source for the solution that you need?

6. Establishing the Groundwork • The next questions • How to characterize good output that would be generated by a successful solution? • What problems will this solution address? • Can show the business environment in which the solution will be used? • Will special performance issues or constraints affect the way the solution is approached? • The final set of questions • Are the answers official? • Are the questions relevant to the problem? • Are too much questions asked? • Can anyone else provide additional information? • Anything else must be asked?

7. Eliciting Requirements • Requirements elicitation (also called requirements gathering) combines elements of problem solving, elaboration, negotiation, and specification. • To encourage a collaborative, team-oriented approach to requirements gathering, stakeholders work together to identify the problem, propose elements of the solution, negotiate different approaches and specify a preliminary set of solution requirements • Collaborative Requirement Gathering • Quality Function Deployment • Usage Scenarios • Elicitation Work Products

8. Collaborative Requirement Gathering • meetings are conducted and attended by both software engineers and customers • rules for preparation and participation are established • an agenda is suggested • a "facilitator" (can be a customer, a developer, or an outsider) controls the meeting • a "definition mechanism" (can be work sheets, flip charts, or wall stickers or an electronic bulletin board, chat room or virtual forum) is used • the goal is • to identify the problem • propose elements of the solution • negotiate different approaches, and • specify a preliminary set of solution requirements

9. Example Consider an excerpt from a product request written by a marketing person involved in the SafeHome project. This person writes the following narrative about the home security function that is to be part of SafeHome: Our research indicates that the market for home management systems is growing at a rate of 40 percent per year. The first SafeHome function we bring to market should be the home security function. Most people are familiar with “alarm systems” so this would be an easy sell. The home security function would protect against and/or recognize a variety of undesirable “situations” such as illegal entry, fire, flooding, carbon monoxide levels, and others. It’ll use our wireless sensors to detect each situation. It can be programmed by the homeowner, and will automatically telephone a monitoring agency when a situation is detected.

10. Mini-spec for the SafeHome object Control Panel The control panel is a wall-mounted unit that is approximately 9 5 inches in size. The control panel has wireless connectivity to sensors and a PC. User interaction occurs through a keypad containing 12 keys. A 3 3 inch LCD color display provides user feedback. Software provides interactive prompts, echo, and similar functions.

12. Some characteristics ofwell statedrequirements • Complete: Each requirement ( Functional and non functional) must fully describe the functionality to be delivered. It contains all of the information necessary for the Developer to design and implement that functionality. • Correct: Each requirement must accurately describe the functionality to be built. • Feasible: It must be possible to implement each requirement within the known capabilities and limitations of the system and its environment. • Unambiguous: All readers should arrive at a single, consistent interpretation of the requirement.

13. Quality Function Deployment • Quality function deployment (QFD) is a quality management technique that translates the needs of the customer into technical requirements for software. • QFD “concentrates on maximizing customer satisfaction from the software engineering process”

14. QFD… • QFD identifies three types of requirements • Normalrequirements • Objectives and goals are stated for product or system during meeting with customer • Requirements present, customer satisfied • Examples: graphical displays, specific system functions, and defined levels of performance

15. QFD… • Expectedrequirements • These requirements are implicit to theproductor system and may be so fundamental that thecustomerdoes not explicitly statethem. • Their absence will be a cause for significantdissatisfaction. • Examples : ease of human/machine interaction, overall operational correctness and reliability, and ease of software installation

16. QFD… • Excitingrequirements • These features go beyond the customer’s expectations and prove to be very satisfying when present. • For example, software for a new mobile phone comes with standard features, but is coupled with a set of unexpected capabilities (e.g., multitouch screen, visual voice mail) that delight every user of the product.

17. Usage Scenarios • As requirements are gathered, an overall vision of system functions and features begins to materialize. • It is difficult to move into more technical software engineering activities until known how these functions and features will be used by different classes of end users. • To accomplish this, developers and users can create a set of scenarios. • The scenarios, often called use cases , provide a description of how the system will be used.

18. Elicitation Work Products For systems, work products may include….. • a statement of need and feasibility. • a bounded statement of scope for the system or product. • a list of customers, users, and other stakeholders who participated in requirements elicitation • a description of the system’s technical environment. • a list of requirements and the domain. • a set of usage scenarios that provide insight into the use of the system or product under different operating conditions. • any prototypesdeveloped to better define requirements.

19. Building the AnalysisModel

20. Building the Analysis Model • Elements of the analysis model • Scenario-based elements • Functional—processing narratives for software functions • Use-case—descriptions of the interaction between an “actor” and the system • Class-based elements • Implied by scenarios • Behavioral elements • State diagram • Flow-oriented elements • Data flow diagram

21. Functional vs. Non-Functional Functional Requirements Non-Functional Functional requirement are user ‘visible’ features and are typically initiated by stakeholders of the system – generate report, login, etc. Non-functional requirements are ‘non-visible’ features and but required for a effective running of an application – security, backup, etc.

22. Use Cases Diagram • Use case diagrams describe what a system does from the standpoint of an external observer. • The emphasis is on what a system does rather than how. • Use case diagrams are closely connected to scenarios. • A scenario is an example of what happens when someone interacts with the system.

23. Use Cases • What is a Use Case???? • A formal way of representing how a business system interacts with its environment • Illustrates the activities that are performed by the users of the system • A scenario-based technique in the UML • A sequence of actions a system performs that yields a valuable result for a particular actor. Use Case Name

24. Use-Cases • Each scenario answers the following questions: • Who is the primary actor, the secondary actor (s)? • What are the actor’s goals? • What preconditions should exist before the story begins? • What main tasks or functions are performed by the actor? • What extensions might be considered as the story is described? • What variations in the actor’s interaction are possible? • What system information will the actor acquire, produce, or change? • Will the actor have to inform the system about changes in the external environment? • What information does the actor desire from the system? • Does the actor wish to be informed about unexpected changes?

25. Actors • An Actor is outside or external the system. • It can be a: • Human • Peripheral device (hardware) • External system or subsystem • Time or time-based event • Represented by stick figure • An actor is who or what initiates the events involved in the task of the use case. • Actors are simply roles that people or objects play. • Two types of Actors 1) Primary Actor 2) Secondary Actor

26. System • The scope of a system can be represented by a system (shape), or sometimes known as a system boundary. • The use cases of the system are placed inside the system shape, while the actor who interact with the system are put outside the system. • The use cases in the system make up the total requirements of the system.

27. Use Case - Relationships • Represent communication between actor and use case • Depicted by line • Also called association relationship Book Appointment Make Appointment

28. Include • Include: a dotted line labeled <<include>> beginning at base use case and ending with an arrows pointing to the include use case. • Use case include is a directed relationship between two use cases which is used to show that behaviour of the included use case (the addition) is inserted into the behaviour of the including (the base) use case. • The include relationship occurs when a chunk of behavior is similar across more than one use case. • Use “include” in stead of copying the description of that behavior. <<include>>

29. Include • A large use case could have some behaviours which might be detached into distinct smaller use cases to be included back into the base use case using the UML include relationship. • The purpose of this action is modularization of behaviours, making them more manageable.

30. Include • Include relationship between use cases is shown by a dashed arrow with an open arrowhead from the including (base) use case to the included (common part) use case.

31. Extend • Extend is a directed relationship that specifies how and when the behaviour defined in usually supplementary (optional) extending use case can be inserted into the behaviour defined in the extended use case. • Extended use case is meaningful on its own, it is independent of the extending use case. • Extending use case typically defines optional behaviour that is not necessarily meaningful by itself.

32. Extend • The base class declares “extension points”. <<extend>> • Extend relationship is shown as a dashed line with an open arrowhead directed from the extending use case to the extended (base) use case. • The arrow is labelled with the keyword «extend».

33. Include and Extend Example

34. Include and Extend Example

35. Extend v/s Include

36. UCD for ATM

37. UCD for Online Shopping

38. ClassName attributes operations Classes • A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics. • Graphically, a class is rendered as a rectangle, usually including its name, attributes, and operations in separate, designated compartments.

39. ClassName attributes operations Class Names • The name of the class is the only required tag in the graphical representation of a class. • It always appears in the top-most compartment.

40. Person name : String address : Address birthdate : Date ssn : Id Class Attributes • An attribute is a named property of a class that describes the object being modeled. • In the class diagram, attributes appear in the second compartment just below the name-compartment.

41. Class Attributes Attributes can be: • + public • # protected • - private • / derived Person + name : String # address : Address # birthdate : Date / age : Date - ssn : Id

42. Person name : String address : Address birthdate : Date ssn : Id eat sleep work play Class Operations • Operations describe the class behavior and appear in the third compartment.

43. Person Person name : String birthdate : Date ssn : Id Person eat() sleep() work() play() Person name address birthdate eat play Depicting Classes When drawing a class, needn’t show attributes and operation in every diagram. Person

44. Class Diagram From the SafeHome system …

45. State Diagram State diagram to specify the sequencing /timing behaviour of objects in a class • States • Action • Events • Transitions

46. State • A state represents a discrete, continuous segment of time wherein the object’s behaviour will be stable • The object will stay in a state until it is stimulated to change by an event Notation Closed

47. At Work entry/unlock door do/prepare materials telephone rings/answer telephone include/lecture state exit/lock door States • For example:

48. Initial and Final State • The initial state of a state machine is indicated with a solid circle • The final state of a state machine is shown as concentric circles go home At Work At Home go to work die die 48

49. Action • is an executable atomic computation • includes operation calls, the creation or destruction of another object, or the sending of a signal to an object • associated with transitions and during which an action is not interruptible -- e.g., entry, exit

50. Event • An event is an instant in time that may be significant to the behaviour of the objects in a class • Events tend to represent - Commands or requests from other objects - Significant times (it’s time to...) - Circumstances or happenings in other objects (the temperature monitor notices the temperature rising over a safety setpoint) - “Custodial” (creation, deletion, simple update)