2. IF2036 Software Engineering TIM RPL Requirement Engineering

3. Requirements Engineering helps software engineers better understand the problems they are trying to solve produce a written understanding of the customer's problem. begins during the software engineering communication activity and continues into the modeling activity * SEPA 6 th ed, Roger S. Pressman

4. What is a Requirement ? It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification. This is inevitable as requirements may serve a dual function – May be the basis for a bid for a contract - therefore must be open to interpretation; – May be the basis for the contract itself - therefore must be defined in detail; – Both these statements may be called requirements. * Software Engineering 7 th ed, Ian Sommerville

5. Types of Requirement User requirements – Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers. System requirements – A structured document setting out detailed descriptions of the system’s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor. * Software Engineering 7 th ed, Ian Sommerville

6. Definitions and Specifications * Software Engineering 7 th ed, Ian Sommerville

7. User Requirements Should describe functional and non- functional requirements in such a way that they are understandable by system users who don’t have detailed technical knowledge. User requirements are defined using natural language, tables and diagrams as these can be understood by all users. * Software Engineering 7 th ed, Ian Sommerville

8. Problems with natural language Lack of clarity – Precision is difficult without making the document difficult to read. Requirements confusion – Functional and non-functional requirements tend to be mixed-up. Requirements amalgamation – Several different requirements may be expressed together. * Software Engineering 7 th ed, Ian Sommerville

9. System Requirements More detailed specifications of system functions, services and constraints than user requirements. They are intended to be a basis for designing the system. They may be incorporated into the system contract. System requirements may be defined or illustrated using system models * Software Engineering 7 th ed, Ian Sommerville

10. Functional and Non-Functional Requirements Functional requirements – Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. Non-functional requirements – constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Domain requirements – Requirements that come from the application domain of the system and that reflect characteristics of that domain. * Software Engineering 7 th ed, Ian Sommerville

11. Functional Requirements Describe functionality or system services. Depend on the type of software, expected users and the type of system where the software is used. Functional user requirements may be high-level statements of what the system should do but functional system requirements should describe the system services in detail. * Software Engineering 7 th ed, Ian Sommerville

12. Non-functional Requirements Examples Product requirement 8.1The user interface for LIBSYS shall be implemented as simple HTML without frames or Java applets. Organisational requirement 9.3.2 The system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP-STAN- 95. External requirement 7.6.5 The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system. * Software Engineering 7 th ed, Ian Sommerville

13. Requirements Measures * Software Engineering 7 th ed, Ian Sommerville

14. Requirements Interaction Conflicts between different non-functional requirements are common in complex systems. Spacecraft system – To minimise weight, the number of separate chips in the system should be minimised. – To minimise power consumption, lower power chips should be used. – However, using low power chips may mean that more chips have to be used. Which is the most critical requirement? * Software Engineering 7 th ed, Ian Sommerville

15. Domain Requirements Derived from the application domain and describe system characteristics and features that reflect the domain. Domain requirements be new functional requirements, constraints on existing requirements or define specific computations. If domain requirements are not satisfied, the system may be unworkable. * Software Engineering 7 th ed, Ian Sommerville

16. Domain Requirements Problems Understandability – Requirements are expressed in the language of the application domain; – This is often not understood by software engineers developing the system. Implicitness – Domain specialists understand the area so well that they do not think of making the domain requirements explicit. * Software Engineering 7 th ed, Ian Sommerville

17. Requirements Completeness and Consistency In principle, requirements should be both complete and consistent. Complete – They should include descriptions of all facilities required. Consistent – There should be no conflicts or contradictions in the descriptions of the system facilities. In practice, it is impossible to produce a complete and consistent requirements document. * Software Engineering 7 th ed, Ian Sommerville

18. Requirements Imprecision Problems arise when requirements are not precisely stated. Ambiguous requirements may be interpreted in different ways by developers and users. Consider the term ‘appropriate viewers’ – User intention - special purpose viewer for each different document type; – Developer interpretation - Provide a text viewer that shows the contents of the document. * Software Engineering 7 th ed, Ian Sommerville

20. Guidelines for Writing Requirements Invent a standard format and use it for all requirements. Use language in a consistent way. Use shall for mandatory requirements, should for desirable requirements. Use text highlighting to identify key parts of the requirement. Avoid the use of computer jargon. * Software Engineering 7 th ed, Ian Sommerville

21. Problems with NL specification Ambiguity – The readers and writers of the requirement must interpret the same words in the same way. NL is naturally ambiguous so this is very difficult. Over-flexibility – The same thing may be said in a number of different ways in the specification. Lack of modularisation – NL structures are inadequate to structure system requirements. * Software Engineering 7 th ed, Ian Sommerville

22. Alternatives to NL specification * Software Engineering 7 th ed, Ian Sommerville

23. The Requirements Document The requirements document is the official statement of what is required of the system developers. Should include both a definition of user requirements and a specification of the system 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 * Software Engineering 7 th ed, Ian Sommerville

24. Users of a Requirements Document * Software Engineering 7 th ed, Ian Sommerville

25. IEEE Requirements Standard Defines a generic structure for a requirements document that must be instantiated for each specific system. – Introduction. – General description. – Specific requirements. – Appendices. – Index. * Software Engineering 7 th ed, Ian Sommerville

26. Requirements Document Structure Preface Introduction Glossary User requirements definition System architecture System requirements specification System models System evolution Appendices Index * Software Engineering 7 th ed, Ian Sommerville

27. Requirement Engineering Tasks Inception – software engineers use context-free questions to establish a basic understanding of the problem, the people who want a solution, the nature of the solution, and the effectiveness of the collaboration between customers and developers Elicitation – find out from customers what the product objectives are, what is to be done, how the product fits into business needs, and how the product is used on a day to day basis Elaboration – focuses on developing a refined technical model of software functions, features, and constraints using the information obtained during inception and elicitation * SEPA 6 th ed, Roger S. Pressman

28. Requirement Engineering Tasks (2) Negotiation – requirements are categorized and organized into subsets, relations among requirements identified, requirements reviewed for correctness, requirements prioritized based on customer needs Specification – written work products produced describing the function, performance, and development constraints for a computer-based system Requirements validation – formal technical reviews used to examine the specification work products to ensure requirement quality and that all work products conform to agreed upon standards for the process, project, and products

29. Initiating Requirements Engineering Process Identify stakeholders Recognize the existence of multiple stakeholder viewpoints Work toward collaboration among stakeholders These context-free questions focus on customer, stakeholders, overall goals, and benefits of the system – Who is behind the request for work? – Who will use the solution? – What will be the economic benefit of a successful solution? – Is there another source for the solution needed? * SEPA 6 th ed, Roger S. Pressman

30. Initiating Requirements Engineering Process The next set of questions enable developer to better understand the problem and the customer's perceptions of the solution – How would you characterize good output form a successful solution? – What problem(s) will this solution address? – Can you describe the business environment in which the solution will be used? – Will special performance constraints affect the way the solution is approached? The final set of questions focuses on communication effectiveness Are you the best person to give "official" answers to these questions? Are my questions relevant to your problem? Am I asking too many questions? Can anyone else provide additional information? Should I be asking you anything else? * SEPA 6 th ed, Roger S. Pressman

31. Eliciting Requirements Collaborative requirements gathering – Meetings attended by both developers and customers – Rules for preparation and participation are established – Flexible agenda is used – Facilitator controls the meeting – Definition mechanism (e.g., stickers, flip sheets, electronic bulletin board) used to gauge group consensus – Goal is to identify the problem, propose solution elements, negotiate approaches, and specify preliminary set of solutions requirements * SEPA 6 th ed, Roger S. Pressman

32. Eliciting Requirements (2) Quality function deployment (QFD) – Identifies three types of requirements (normal, expected, exciting) – In customer meetings function deployment is used to determine value of each function that is required for the system – Information deployment identifies both data objects and events that the system must consume or produce (these are linked to functions) – Task deployment examines the system behavior in the context of its environment – Value analysis is conducted to determine relative priority of each requirement generated by the deployment activities User-scenarios – Also known as use-cases, describe how the system will be used – Developers and users create a set of usage threads for the system to be constructed * SEPA 6 th ed, Roger S. Pressman

33. Elicitation Work Products Statement of need and feasibility Bounded statement of scope for system or product List of stakeholders involved in requirements elicitation Description of system's technical environment List of requirements organized by function and applicable domain constraints Set of usage scenarios (use-cases) that provide use insight into operation of deployed system Prototypes developed to better understand requirements * SEPA 6 th ed, Roger S. Pressman

34. Requirements Elaboration Developing Use-Cases – Each use-case tells stylized story about how end-users interact with the system under a specific set of circumstances Analysis Model – Intent is to provide descriptions of required information, functional, and behavioral domains for computer-based systems – Analysis Model Elements Scenario-based elements (describe system from user perspective) Class-based elements (relationships among objects manipulated by actors and their attributes) Behavioral elements (depict system and class behavior as states and transitions between states) Flow-oriented elements (shows how information flows through the system and is transformed by the system functions) * SEPA 6 th ed, Roger S. Pressman

35. Negotiating Requirements Negotiation activities – Identification of system key stakeholders – Determination of stakeholders' "win conditions" – Negotiate to reconcile stakeholders' win conditions into "win-win" result for all stakeholders (including developers) Key points – It's not a competition – Map out a strategy – Listen actively – Focus on other party's interests – Don't let it get personal – Be creative – Be ready to commit * SEPA 6 th ed, Roger S. Pressman

36. Requirements Validation Concerned with demonstrating that the requirements define the system that the customer really wants. Requirements error costs are high so validation is very important – Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error. * Software Engineering 7 th ed, Ian Sommerville

37. Requirements Checking Validity. Does the system provide the functions which best support the customer’s needs? Consistency. Are there any requirements conflicts? Completeness. Are all functions required by the customer included? Realism. Can the requirements be implemented given available budget and technology Verifiability. Can the requirements be checked? * Software Engineering 7 th ed, Ian Sommerville

38. Requirements Validation Techniques Requirements reviews – Systematic manual analysis of the requirements. Prototyping – Using an executable model of the system to check requirements. Test-case generation – Developing tests for requirements to check testability. * Software Engineering 7 th ed, Ian Sommerville

39. Requirement Review Is each requirement consistent with overall project or system objective? Are all requirements specified at the appropriate level off abstraction? Is each requirement essential to system objective or is it an add-on feature? Is each requirement bounded and unambiguous? Do you know the source for each requirement? Do requirements conflict with one another? Is the requirement achievable in the proposed technical environment for the system or product? Is each requirement testable? Does the requirements model reflect the information, function, and behavior of the system to be built? Has the requirements model been partitioned in a way that exposes more detailed system information progressively? Have all the requirements patterns been properly validated and are they consistent with customer requirements? * SEPA 6 th ed, Roger S. Pressman

40. Requirements Management help project team to identify, control, and track requirements and changes as project proceeds many of these activities are identical to the software configuration management (SCM) process * SEPA 6 th ed, Roger S. Pressman

41. Requirements Management Process: – requirements are identified, – tagged with a unique identifier and – classified by type (functional, data, behavioral, interface, or output) Tools: – Traceability tables developed and updated any time a requirement is modified – Database systems invaluable in helping software teams track requirement changes * SEPA 6 th ed, Roger S. Pressman

42. Requirements Change The priority of requirements from different viewpoints changes during the development process. System customers may specify requirements from a business perspective that conflict with end-user requirements. The business and technical environment of the system changes during its development. * Software Engineering 7 th ed, Ian Sommerville

43. Requirements Classification * Software Engineering 7 th ed, Ian Sommerville

44. CASE Tool Support Requirements storage – Requirements should be managed in a secure, managed data store. Change management – The process of change management is a workflow process whose stages can be defined and information flow between these stages partially automated. Traceability management – Automated retrieval of the links between requirements. * Software Engineering 7 th ed, Ian Sommerville

45. Requirements Change Management Should apply to all proposed changes to the requirements. Principal stages – Problem analysis. Discuss requirements problem and propose change; – Change analysis and costing. Assess effects of change on other requirements; – Change implementation. Modify requirements document and other documents to reflect change. * Software Engineering 7 th ed, Ian Sommerville