Requirements Elicitation

1. Requirements Elicitation Lectures 10 & 11

2. References • Chapter 4: Requirements Elicitation from Object Oriented Software Engineering: Conquering Complex and Changing Systems.

3. Introduction • Requirement is a feature that the system must have or a constraint that it must satisfy to be accepted by a client. • Requirements engineering aims at defining the requirements of the system under consideration. • Requirements engineering consists of two main activities • Requirements Elicitation • Results in the specification of the system that the client understands • Analysis • Results in a model that the developers can unambiguously interpret.

4. Tools to Bridge the Knowledge Divide • Clients and users are domain experts. • Developers have knowledge to build systems. • Scenarios and use cases are used to bridge the knowledge gap. • Scenarios describe examples of system use in terms of series of interactions between the user and the system. • Use cases are abstractions that describe classes of scenarios. • Developers and clients should be able to understand both.

5. Requirements Elicitation • Successful requirements elicitation depends upon communication between clients and developers. • Imperfect and error prone communication results in an unusable and/or useless system. • Erroneous requirements • Are expensive to correct. • Are discovered late during the development stage. • May require significant changes in the developed system.

6. Requirements Elicitation(Contd.) • Requirements elicitation focuses on describing the purpose of the system. • Allows the development of system specifications, • Identification of problem area and definition of a system to solve the problems. • System specification is structured and formalised during analysis to produce an analysis model. • System specification and analysis model represent the same information with different notations and language.

7. Requirements Elicitation(Contd.) • System specification supports the communication between clients and developers. • Analysis model supports the communication among developers. • Both models represent external aspects of the system and therefore occur concurrently and iteratively. • Both models focus on the user’s view of the system. • Aspects of the system that are not directly visible to the user do not form a part of the requirements.

8. Requirements Elicitation Activities • Identification of actors • i.e., different types of users the future system will support. • Identification of scenarios • i.e., examples of future system in use. • Developers use scenarios to communicate with users to enhance their understanding of the problem domain. • Identification of use cases • Transformation of scenarios into use cases that completely represent the future system. • Use cases are abstractions determining the complete scope of the system.

9. Requirements Elicitation Activities(Contd.) • Refinement of use cases • Developers ensure that the functionality of the system is complete. • Involves detailing each use case and describing the behaviour of the system in the presence of errors and exceptions. • Identification of relationships between use cases • Consolidation of use case model through elimination of redundancies. • Ensures the consistency of system specification.

10. Requirements Elicitation Activities(Contd.) • Identification of nonfunctional requirements • Developers, clients and users agree on aspects that are visible to the system but not directly related to the functionality. • e.g., • Constraints on performance of the system. • Documentation. • Resources consumed by the system. • Security • Quality

11. Information used in Elicitation • Client supplied documents about the application domain. • Manuals and technical documentation about the legacy system. • Documentation on users and clients, • Qualifications, • Roles, • Tasks, • Resources

12. Elicitation Methods • Joint Application Design (JAD) • Focuses on building consensus among developers, users and clients by jointly developing the system specification. • Knowledge Analysis of Tasks (KAT) • Focuses on eliciting requirements from users through observation. • Usability Testing • Focuses on validating the requirements elicitation model with the user through a variety of methods.

13. Functional Requirements • Describe the interactions between the system and its environment independent of its implementation. • Environment includes • Users • Any other system that the system being developed has to interact with. • This description does not focus on any of the implementation details • E.g., processor, language, display technology.

14. Functional Requirements: Example • Distributed flight planning and scheduling system. It is supposed to be an online system involving an interaction between a central CAA server that will maintain data on flight corridors, a meteorological server that contain data on weather information at flight terminal (i.e., airfields) and individual flight terminal servers that contain information on airfield status, rescue and crash facilities, emergency services, etc. on that particular airfield. • Once a pilot submits a request for a flight plan indicating the flight terminals and the tentative start and end times of the flight, the system collects flight corridor information, enroute and terminal weather conditions and terminal status and provides the following information to the pilot for every flight corridor that is available, • Waypoints, • Altitude for each leg, • Tentative start time and end time, • Alternative emergency terminals for each leg, • Weather information for each leg and at terminals. • The pilot can select one flight plan that corresponds to the flight corridors specified by the system. This system should be web-enabled and can be integrated with an IVR (Integrated voice response) enable call center where people can dial for flight enquiries.

15. Non-Functional Requirements • Describe user visible aspects of the system that are not directly related to the functional behaviour of the system. • May include • Quantitative constraints • E.g., response time, throughput, etc. • Accuracy

16. Pseudo Requirements • Requirements imposed by the client that restrict the implementation of the system. • Typical pseudo requirements • Implementation platform • Programming language • For life-critical systems, pseudo requirements include process and documentation requirements. • Usually have no direct effect on the user’s view of the system.

17. Levels of Description of Requirements • Work Division • Set of use cases describing the work processes of the users that are relevant to the system. • Application Specific System Functions • Set of use cases describing the application domain related functions that the system provides. • Work Specific System Functions • Set of use cases describing supporting functions. • Dialog • Set of use cases describing the interaction between the users and user interface of the system.

18. Requirements Validation • Requirements are continuously validated with the clients and the users. • Validation is a critical step in the development process, • Both the client and the developer are dependent on system specifications. • Involves checking if the specification is • Correct • Complete • Consistent • Unambiguous • Realistic

19. Requirements Validation(Contd.) • Correctness • A specification is correct if it is correct if it represents a client’s view of the system. • Completeness • A specification is complete if all possible scenarios through the system including exceptional behaviour are described. • Consistency • A specification is consistent if it does not contradict itself.

20. Requirements Validation(Contd.) • Clarity • A specification is unambiguous if cannot be interpreted in ways more than one. • Realism • A specification is realistic if the system can be implemented within constraints.

21. Requirements Verifiability and Traceability • Verifiability • A specification is verifiable if, once the system is built, a repeatable test can be designed to demonstrate that the system fulfils the requirement. • Traceability • A system specification is traceable if each system can be traced to its corresponding set of requirements. • Traceability is not a constraint of the content of the specification but on its organisation. • Traceability facilitates the development of tests and the systematic validation of the design against requirements.

22. Greenfield Engineering • Development starts from scratch. • No prior system exists. • A greenfield project is triggered by a user need or the creation of a new market. • Requirements are extracted from users and clients, i.e., the application domain.

23. Reengineering • Redesign and reimplementation of the existing system triggered by technology enablers or by new information flow. • Sometimes the functionality of the new system is extended when the essential purpose of the system remains the same. • Requirements for the new system can be extracted from an existing system.

24. Interface Engineering • Redesign of the user interface of an existing system. • Only the user interface of the legacy system is changed. • The legacy system cannot be discarded without entailing a high cost.

25. Actors • Actors represent external entities that interact with the system and exchange information. • Actors define classes of functionality. • Actors are role abstractions and do not necessarily directly map to persons. • The functionality each actor accesses is substantially different from the functionality of other actors.

26. Identifying Actors • Identification of actors in a system is the first step in requirements elicitation. • Identification of actors is used to • define the boundaries of the system, • to find all the perspectives from which the developers need to consider the system. • When a system is developed for an existing organisation, most actors usually exist before the system is developed. • They correspond to roles in the organisation.

27. Identifying Actors(Contd.) • Who are the actors? • User groups that are supported by the system to perform their work. • User groups that execute the system’s main functions. • User groups that perform secondary functions. • E.g., maintenance, administration. • Any external hardware or software that the system interacts with. • After identifying the actors, functionality accessible to each actor is to be determined. • This information is extracted using scenarios and formalised using use cases.

28. Example: Actors • FRIEND: a distributed system for accident management. • Actors • FieldOfficers: represent police and fire officers who respond to an incident. • Dispatchers: police officers responsible for answering 911 calls and dispatching resources to an incident. • Actors interact with the system through different interfaces.

29. Example: Actors(Contd.)

30. Scenarios • A scenario is a narrative description of what actors do and experience as they try to use computers and applications. • A scenario is a concrete, focused and informal description of a single feature of the system from the viewpoint of a single actor. • Scenario focus around the work that the system performs rather than the system itself. • Scenarios are open-ended and informal, and cannot completely replace traditional approaches.

31. Types of Scenarios • As-is Scenario • Used to describe a current situation. • Based on the observation of users and their actions. • Validated for correctness and accuracy with the users. • Visionary Scenarios • Describe a future system, either reengineered or designed from scratch. • Used both as • Coarse design representations • Communication mechanism to elicit requirements from users • Can be viewed as inexpensive prototypes.

32. Types of Scenarios(Contd.) • Evaluation Scenarios • Describe user tasks against which the system is to be evaluated. • Collaborative development by users and developers also improves the definition of the functionality tested by these scenarios. • Training Scenarios • Tutorials used for introducing new users to the system. • Step by step instructions designed to hand-hold the user through common tasks.

33. Identifying Scenarios • Developers and users write and refine a series of scenarios to gain a shared understanding of the system. • Initially each scenario may be high level and incomplete. • Scenarios should be documented in application domain related terminologies. • Scenarios can be incrementally and iteratively refined to include increasing amounts of details.

34. Identifying Scenarios(Contd.) • What are scenarios • Tasks the actor wants the system to perform. • Information and the manner in which it is accessed. • External changes the actor needs to inform the system about. • System events that need to be notified to the actor. • Actor and scenario identification allows developers to understand the application domain. • Scenarios are formalised into use cases.

35. Example: Scenario

36. Use Cases • A scenario is an instance of a use case. • A use case specifies all possible scenarios for a given aspect of functionality. • A use case is initiated by an actor. • After its initiation, a use case may interact with other actors as well. • A use case represents a complete flow of events through the system. • A series of related interactions is described that results from the initiation of the use case.

37. Example: Use Case

38. Example: Use Case (Contd.)

39. Heuristics for writing scenarios and use cases • Use scenarios to communicate with users and to validate functionality. • First, refine a narrow vertical slice(i.e. one scenario) to understand the user’s preferred style of interaction. • Next, define a horizontal slice(i.e. many not very detailed scenarios) to define the scope of the system. Validate with the user. • Use mock-ups as a visual support only; user interface design should occur as a separate task once the functionality is sufficiently stable.

40. Heuristics for writing scenarios and use cases (Contd.) • Present the user with multiple alternatives(as opposed to extracting a single alternative from the user). • Detail a broad vertical slice when the scope of the system and the user preferences are well understood. Validate with the user.

41. Identifying Relationships among Actors and Use Cases • Relationships among actors and use cases enable the developers and users to reduce the complexity of the model and increase its understandability. • Communication relationships between actors and use cases are used to describe the system in layers of functionality. • Relationships are extended to separate exceptional and common flows of events. • Include relationships between use cases reduces redundancy among use cases.

42. Communication Relationship between Actors and Use Cases • Used to represent the flow of information during the use case. • The actors initiating the use case should be distinguished from other actors the use case communicates with. • Access control can be represented at this level. • Relationships between actors and use cases are identified when use cases are identified.

43. Communication Relationships among Actors and Use Cases: Example

44. Extend Relationship between Use Cases • A use case extends another use case if the extended use case may include the behavior of the extension under certain conditions. • Advantages of separating exceptional and optional flows of events from the base use case are • Base use cases become shorter and easier to understand. • Common case is distinguished from exceptional enabling the developer to treat each type of functionality differently.

45. Extend Relationship between Use Cases (Contd.) • Base use cases and exceptions are complete use cases. • Both have entry and exit conditions. • Both are understandable by the user as an independent whole.

46. Extend Relationship: Example

47. Include Relationship between Use Cases • Used to factor out redundancies among use cases. • Advantages of factoring out shared behavior from use cases are • Shorter descriptions • Fewer redundancies • Behavior should only be factored out into a separate use case if it is shared across two or more use cases. • Excessive fragmentation of system specification over a large number of use cases makes the specifications confusing to user and clients.

48. Include Relationship: Example

49. Extend Vs. Include Relationships • Similar but confusing constructs. • Main distinction is the direction of the relationship. • In the includes relationship conditions under which the target use case is initiated are described in the initiating use case. • In the extends relationship, the conditions under which the extension is initiated are described in the extension as an entry condition.

50. Non Functional Requirements • Describe user-visible aspects of the system not directly related to the functional behavior of the system. • Span a number of issues, e.g., • User interface look and feel • Performance issues • Security • Should be defined with the functional requirements as they have an impact on the development and cost of the system.