Inah Omoronyia Requirements Handling

1. Institutt for datateknikk og informasjonsvitenskap Inah Omoronyia Requirements Handling TDT 4242 TDT 4242

2. Requirements Handling • Focus point (1): • Characteristics of an effective RE process: • Minimises the occurrence of requirements errors • Mitigates the impact of requirements change • Is critical to the success of any development project. • Focus point (2): • The RE process is always aimed at a stage where a requirement for a system property can confidently be allocated to a particular software component that assumes responsibility for satisfying the requirement. • When such allocation is possible: • the resulting software is well modularised. • the modules have clear interfaces with each other • and all requirements are cleanly separated. TDT 4242

3. Requirements Handling • Focus point (3): • Subset of criteria for good requirements handling • Handle the different view points of the system-to-be • Handling of non-functional requirements and soft goals • The identification and handling of crosscutting and non-crosscutting requirements • The impact of COTS, outsourcing/sub-contracting TDT 4242

4. Requirement handling –Viewpoint • Viewpoints, perspectives and views • Viewpoint is defined as a standing position used by an individual when examining a universe of discourse. • The combination of the agent and the view that the agent holds • A perspective is defined as a set of facts observed and modelled according to a particular aspect of reality • A view is defined as an integration of these perspectives • A viewpoint language is used to represent the viewpoints TDT 4242

5. Requirement handling –Viewpoint • Example: • Consider the requirements for a system to be installed on a train which will automatically bring the train to a halt when it wrongly goes through a danger signal • Some examples of viewpoints for this system and the requirements they encapsulate might be: • DriverRequirements from the train driver on the system • Trackside equipment Requirements from trackside equipment which must interface with the system to be installed • Safety engineerSafety requirements for the system • Existing on-board systemsCompatibility requirements • Braking characteristics Requirements which are derived from the braking characteristics of a train. TDT 4242

6. Requirement handling –Viewpoint • Example: ATM Viewpoints • Bank customers • Representatives of other banks • Hardware and software maintenance engineers • Marketing department • Bank managers and counter staff • Database administrators and security staff • Communications engineers • Personnel department TDT 4242

7. Requirement handling –Viewpoint • Types of viewpoints • Data sources or sinks • Viewpoints that are responsible for producing or consuming data. Analysis involves checking that data is produced and consumed and that assumptions about the source and sink of data are valid • Representation frameworks • Viewpoints that represent particular types of system model (e.g. State machine representation). Particularly suitable for real-time systems • Receivers of services • Viewpoints that are external to the system and receive services from it. Most suited to interactive systems TDT 4242

8. Requirement handling –Viewpoint • The VORD method • Is a method designed as a service-oriented framework for requirements elicitation and analysis. Viewpoint Identification Viewpoint Structuring Viewpoint Documentation Viewpoint System mapping TDT 4242

9. Requirement handling –Viewpoint • The VORD method • Viewpoint identification • Discover viewpoints which receive system services and identify the services provided to each viewpoint • Viewpoint structuring • Group related viewpoints into a hierarchy. Common services are provided at higher-levels in the hierarchy • Viewpoint documentation • Refine the description of the identified viewpoints and services • Viewpoint-system mapping • Transform the analysis to an object-oriented design TDT 4242

10. Requirement handling –Viewpoint • VORD standard forms Viewpoint template Reference: The view point name Attributes: Attributes providing viewpoint information Events: A reference to a set of event scenarios describing how the system reacts to viewpoint events Services: A reference to a set of service descriptions Sub-VPs: The names of sub-viewpoints Service template Reference: The service name Rationale: Reason why the service is provided. Specification: Reference to a list of service specifications. These may be expressed in different notations. Viewpoints: A List of viewpoint names receiving the service Non-functional requirements: Reference to a set of non-functional requirements which constrain the service. Provider: Reference to a list of system objects which provide the service. TDT 4242

11. Requirement handling –Viewpoint • Viewpoint: Service Information ACCOUNT HOLDER FOREIGN CUSTOMER BANK TELLER Service list Withdraw cash Query balance Order checks Send message Transaction list Order statement Transfer funds Service list Withdraw cash Query balance Service list Run diagnostics Add cash Add paper Send message TDT 4242

12. Requirement handling –Viewpoint • Viewpoint hierarchy All Viewpoints Services Query balance Withdraw cash Customer Bank staff Services Order checks Send message Transaction list Order statement Transfer funds Account holder Account holder Teller Manager Engineer TDT 4242

13. Requirement handling –Viewpoint • Customer/cash withdrawal templates Reference: Customer Attributes: Account number; PIN; Start transaction Events: Select service; Cancel transaction; End transaction Services: Cash withdrawal Balance inquiry Sub-Viewpoints: Account holder Foreign customer Reference: Cash withdrawal Rationale: To improve customer service and reduce paperwork Specification: Users choose this service by pressing the cash withdrawal button. They then enter the amount required. This is confirmed and, if funds allow, the balance is delivered. Viewpoints: Customer Non-functional requirements: Deliver cash within 1minute of amount being confirmed Provider: __________ TDT 4242

14. Requirement handling –Viewpoint • Advantages of viewpoint-oriented approaches in requirements handling: • Viewpoints assist in understanding and controlling the complexity by separating interests of various actors • They explicitly recognise the diversity of sources of requirements • They provide a mechanism for organising and structuring this diverse information • They imparts a sense of thoroughness (completeness) • They provide a means for requirements sources or stakeholders to identify and check their contribution to the requirements TDT 4242

15. Requirements handling: NFR and soft goals Scenario: Imagine that you have been asked by your client to conduct a requirements analysis for a new system intended to support various office functions within its organization, including scheduling meetings. Clients success criterion: The new system should be highly usable, flexible and adaptable to the work patterns of individual users and that its introduction should create as little disruption as possible. Question: how are you going to deal with the client’s objectives of having a usable and flexible system? Challenge: We need some way to represent flexibility and usability concern, along with their respective interrelationships. TDT 4242

16. Requirements handling: NFR and soft goals • Non-Functional Requirements Framework (NFRF) Mylopoulos et.al.: • The concept of goal is used extensively in AI where a goal is satisfied absolutely when its subgoals are satisfied. • But NFRF is centred around the notion of softgoals which do not have a clear-cut criterion for their satisfaction • Softgoals are satisficed when there is sufficient positive and little negative evidence for this claim, and that they are unsatisficeable when there is sufficient negative evidence and little positive support for their satisficeability. TDT 4242

17. Requirements handling: NFR and soft goals • Non-Functional Requirements Framework (NFRF): • Softgoals are not analysed independently of one another, but rather in relation to each other. Softgoal relationships TDT 4242

18. Requirements handling: NFR and soft goals • Non-Functional Requirements Framework (NFRF): • Non-functional requirements analysis: • Step1:Begins with softgoals that represent non-functional requirements agreed upon by the stakeholders, say Usability, Flexibility, etc. • Step 2:Each softgoal is then refined by using decomposition methods. • Decomposition methods: • Can be based on general expertise/knowledge about security, flexibility etc. • Or domain-specific knowledge is needed (in this case domain knowledge specific to meeting scheduling) • Or even project-specific (decided upon jointly by the stakeholders of the project) TDT 4242

19. Requirements handling: NFR and soft goals • Non-Functional Requirements Framework (NFRF): • Non-functional requirements analysis: Example (partial) result of flexibilitysoftgoal decomposition for of nonfunctional requirements analysis for an office support system Flexibility ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ Access of other staff’s files Future Growth Flexible work patterns Sharing ofInformation Separate Performance Standards Design for Modularity Design for Extra Terminals Task switching TDT 4242 Access of database Flexibility softgoal decomposition

20. Requirements handling: NFR and soft goals • Non-Functional Requirements Framework (NFRF): • Non-functional requirements analysis: Also involves finding lateral relationship the softgoals of individual softgoal trees • Example: Performance goals generally interferes with flexibility. Databases interferes with security goals at some level. - Usability - Performance + Flexibility ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ - Access of other staff’s files + Future Growth Profitability Flexible work patterns Sharing ofInformation + - Maintainability - Security - Separate Performance Standards Design for Modularity Design for Extra Terminals Task switching Security Performance TDT 4242 Access of database Flexibility softgoal decomposition and interference with softgoals belonging to different softgoal tree structures

21. Requirement handling – NFR and soft goals • Advantages of Non-Functional Requirements Framework (NFRF): • NFR are obtained by gathering knowledge about the domain for which a system will be built. • NFRF focuses on clarifying the meaning of non-functional requirements • NFRF provides alternatives for satisfying softgoals to the highest possible level, considering the conflicts between them. TDT 4242

22. Requirement handling – Cross-cutting requirements • Challenges (1): • How do we deal with cross-cutting concerns in goals requirements and constraints • A sub-goal, concrete requirements, etc.. Can be involved in the satisfaction of more than one higher level goal representation. • An agent in most cases is involved in executing a number of system behavior. Goal Sub goals Derived/concrete requirements, design constraints, assumptions/expectations Agents TDT 4242

23. Requirements handling: Cross-cutting requirements Challenges (2): How do we deal with cross cutting requirements and constraints that come from different sources. Example: embedded systems, IS, COTS- Commercial, off-the-shelf) Requirements /Constraints Problem domain Solution Space Market forces Operational context Proposed solution Problem definition Organisational context Requirements, Constraints, Problems and Solutions in RE TDT 4242

24. Requirements handling: Cross-cutting requirements • The cross cutting attribute results in requirements without clear distinct/atomic allocation into modules. • Many non-functional requirements fall into this category. • Example: • Performance is a factor of the system architecture and its operational environment; one cannot develop a performance module independent of other parts of a software system. • Such requirements are termed crosscutting (or aspectual) requirements. Examples of such properties include security, mobility, availability and real-time constraints. TDT 4242

25. Requirements handling: Cross-cutting requirements • Early Aspects (Aspects oriented requirements engineering): • Concerned with identifying cross-cutting concerns early during requirements engineering and architecture design phase rather than during implementation. • This involves four basic steps: • Identify • Capture • Compose • and analyze. TDT 4242

26. Requirements handling: Cross-cutting requirements • Early Aspects (Aspects oriented requirements engineering): • Example scenario: Consider a banking system with many requirements and include the following: • Requirements A • Pay interest of a certain percent on each account making sure that the transaction is fully completed and an audit history is kept. • Allow customers to withdraw from their accounts, making sure that the transaction is fully completed and an audit history is kept. TDT 4242

27. Requirements handling: Cross-cutting requirements • Early Aspects (Aspects oriented requirements engineering): • Example scenario: • Central concerns revealed in requirements A: • “pay interest,” “withdrawal,” “complete in full,” and “auditing” • Of those concerns, “pay interest” and “withdrawal” are described in separate requirements. • However, “complete in full” and “auditing” are each described in both requirements 1 and 2. • Main challenge in requirements A: • Concerns are scattered across the requirement set • If we want to find out which transactions should be fully completed or audited, we must sift through the whole requirements set for references to transactions and auditing. TDT 4242

28. Requirements handling: Cross-cutting requirements • Early Aspects (Aspects oriented requirements engineering): • Example scenario: Attempt to rewrite the requirements A to remove scattered concepts: • Requirements B • 1Δ. Pay interest of a certain percent on each account. • 2Δ. Allow customers to withdraw from their accounts. • 3. Make sure all transactions are fully completed. • 4. Keep an audit history of all transactions. • Main challenge in requirements B: • This rewriting introduces implicit tangling between the newly separated concerns (“auditing” and “complete in full”) and the other concerns (“pay interest” and “withdrawal”). • You can’t tell, without an exhaustive search, which transactions the “complete in full” and “auditing” properties affect. TDT 4242

29. Requirements handling: Cross-cutting requirements • Early Aspects (Aspects oriented requirements engineering): • Example scenario: The broadly scoped concerns are considered as aspects (i.e. “complete in full” and “auditing” properties) • Requirements C (Aspect Oriented (AO) solution) • 1Δ Pay interest of a certain percent on each account. • 2Δ Allow customers to withdraw from their accounts. • 3Δ To fully complete a transaction… • 3A List of transactions that must be fully completed: {1Δ, 2Δ} • 4Δ To audit… • 4A List of transactions that must leave an audit history: {1Δ, 2Δ} • The AO solution is to make the impact explicit by modularizing aspects into two sections: • one that describes the requirements of the aspect concern itself (3Δ, 4Δ) • and another that describes the breadth of its impact (3A, 4A). TDT 4242

30. Requirement handling – Cross-cutting requirements • Advantages early aspects: • Captures the core or base concerns (“withdrawal” and “pay interest”): 1Δ, 2Δ • Captures cross-cutting concerns as aspects: 3Δ, 4Δ • Describes Impact requirements: a requirement describing the influence of one concern over other concerns: 3A, 4A TDT 4242

31. Requirement handling – COTS • As the size and complexity of systems continues to grow the use of commercial off the shelf (COTS) components is being viewed as a possible solution. • In this case requirements are constrained by the availability of suitable COTS component. • Early evaluation of candidate COTS software products is a key aspect of the system development lifecycle. TDT 4242

32. Requirement handling – COTS • The impact of using COTS based components is expected to vary with the domain: • For business applications a large, pervasive COTS product may be used to deliver one or more requirements (e.g., MS Office, Oracle, Netscape, etc.). • For embedded real time or safety critical domains, the COTS components are expected to be smaller and require large amounts of glue code to integrate the set of components TDT 4242

33. Requirement handling – COTS • Issues with COTS: • Organisations have very limited access to product’s internal design. • Sometimes description of commercial packages is incomplete and confusing. • Customers have limited chance to verify in advance whether the desired requirements are met. • In practice, most selection decisions are based on subjective judgements, such as current partnerships, commercial profits, and successful vendor marketing. • Advantages with COTS: • Customers can take the advantage that a product that has been tested many times by real-world users with consequent improvement in software quality. TDT 4242

34. Requirement handling – Outsourcing • Outsourcing/subcontracting: • Is a management strategy by which an organization outsources/contracts out major, non-core functions to specialized, efficient service providers and third parties. • Is a rapidly growing market all over the world. • Types: • Onshore outsourcing: outsourcing a project within own country • Offshore outsourcing:Includes outsourcing services offered by countries outside Europe, typically overseas • Nearshore outsourcing:E.g., for Scandinavian countries nearshore might be Baltic countries TDT 4242

35. Requirement handling – Outsourcing • Outsourcing/subcontracting: • Phases: • Selection: This is about selecting the subcontractor and is synonymous to tendering. • Monitoring: This phase starts with the signed contract and follows the subcontractor’s work till the product is delivered. • Completion: It includes acceptance and installation of the product, and in many cases also the maintenance of the product over its lifetime TDT 4242

36. Requirement handling – Outsourcing • Outsourcing/subcontracting: • Advantages: • Cost savings • Improving service delivery and quality (is gaining in importance) • Keeping pace with technological innovation • Disadvantage: • Companies will lose control over business process and in-house expertise. TDT 4242

37. Conclusion • There are different approaches for identifying and handling requirements that are inherently complex, interdependent and multi-faceted. • Viewpoints aims to explicitly model the interest of various actors. • Non-functional requirements framework focuses on explicit modeling of softgoals and clarifying their meaning • Early aspects focuses on identifying cross-cutting concerns in requirements at the early phase of a project lifecycle. • There is additional requirements handling consideration when when using COTS components, outsourcing or sub-contracting TDT 4242

38. Reading materials • Mylopoulos, J., Chung, L., and Yu, E. 1999. From object-oriented to goal-oriented requirements analysis. Commun. ACM • http://www.early-aspects.net/ • Sommerville, I., Sawyer, P., 1998. Viewpoints for requirements elicitation: a practical approach. 3rd International Conference on requirements Engineering. • Ian Sommerville’s “Software Engineering” • Edition 6: Chapter 5, 6. • Edition 7/8: Chapter 6, 7. TDT 4242