Содержание
- 2. Topics covered Functional and non-functional requirements Requirements engineering processes Requirements elicitation Requirements specification Requirements validation Requirements
- 3. Requirements engineering The process of establishing the services that acustomer requires from a system and the
- 4. What is a requirement? It may range from a high-level abstract statement of a service or
- 5. Requirements abstraction (Davis) Chapter 4 Requirements Engineering “If a company wishes to let a contract for
- 6. Types of requirement User requirements Statements in natural language plus diagrams of the services the system
- 7. User and system requirements Chapter 4 Requirements Engineering 30/10/2014
- 8. Readers of different types of requirements specification Chapter 4 Requirements Engineering 30/10/2014
- 9. System stakeholders Any person or organization who is affected by the system in some way and
- 10. Stakeholders in the Mentcare system Patients whose information is recorded in the system. Doctors who are
- 11. Stakeholders in the Mentcare system A medical ethics manager who must ensure that the system meets
- 12. Agile methods and requirements Many agile methods argue that producing detailed system requirements is a waste
- 13. Functional and non-functional requirements Chapter 4 Requirements Engineering 30/10/2014
- 14. Functional and non-functional requirements Functional requirements Statements of services the system should provide, how the system
- 15. Functional requirements Describe functionality or system services. Depend on the type of software, expected users and
- 16. Mentcare system: functional requirements A user shall be able to search the appointments lists for all
- 17. Requirements imprecision Problems arise when functional requirements are not precisely stated. Ambiguous requirements may be interpreted
- 18. Requirements completeness and consistency In principle, requirements should be both complete and consistent. Complete They should
- 19. Non-functional requirements These define system properties and constraints e.g. reliability, response time and storage requirements. Constraints
- 20. Types of nonfunctional requirement Chapter 4 Requirements Engineering 30/10/2014
- 21. Non-functional requirements implementation Non-functional requirements may affect the overall architecture of a system rather than the
- 22. Non-functional classifications Product requirements Requirements which specify that the delivered product must behave in a particular
- 23. Examples of nonfunctional requirements in the Mentcare system Chapter 4 Requirements Engineering 30/10/2014
- 24. Goals and requirements Non-functional requirements may be very difficult to state precisely and imprecise requirements may
- 25. Usability requirements The system should be easy to use by medical staff and should be organized
- 26. Metrics for specifying nonfunctional requirements Chapter 4 Requirements Engineering 30/10/2014
- 27. Requirements engineering processes Chapter 4 Requirements Engineering 30/10/2014
- 28. Requirements engineering processes The processes used for RE vary widely depending on the application domain, the
- 29. A spiral view of the requirements engineering process Chapter 4 Requirements Engineering 30/10/2014
- 30. Requirements elicitation Chapter 4 Requirements Engineering 30/10/2014
- 31. Requirements elicitation and analysis Sometimes called requirements elicitation or requirements discovery. Involves technical staff working with
- 32. Requirements elicitation Chapter 4 Requirements Engineering 30/10/2014
- 33. Requirements elicitation Software engineers work with a range of system stakeholders to find out about the
- 34. Problems of requirements elicitation Stakeholders don’t know what they really want. Stakeholders express requirements in their
- 35. The requirements elicitation and analysis process Chapter 4 Requirements Engineering 30/10/2014
- 36. Process activities Requirements discovery Interacting with stakeholders to discover their requirements. Domain requirements are also discovered
- 37. Requirements discovery The process of gathering information about the required and existing systems and distilling the
- 38. Interviewing Formal or informal interviews with stakeholders are part of most RE processes. Types of interview
- 39. Interviews in practice Normally a mix of closed and open-ended interviewing. Interviews are good for getting
- 40. Problems with interviews Application specialists may use language to describe their work that isn’t easy for
- 41. Ethnography A social scientist spends a considerable time observing and analysing how people actually work. People
- 42. Scope of ethnography Requirements that are derived from the way that people actually work rather than
- 43. Focused ethnography Developed in a project studying the air traffic control process Combines ethnography with prototyping
- 44. Ethnography and prototyping for requirements analysis Chapter 4 Requirements Engineering 30/10/2014
- 45. Stories and scenarios Scenarios and user stories are real-life examples of how a system can be
- 46. Photo sharing in the classroom (iLearn) Jack is a primary school teacher in Ullapool (a village
- 47. Scenarios A structured form of user story Scenarios should include A description of the starting situation;
- 48. Uploading photos iLearn) Initial assumption: A user or a group of users have one or more
- 49. Uploading photos What can go wrong: No moderator is associated with the selected project. An email
- 50. Requirements specification Chapter 4 Requirements Engineering 30/10/2014
- 51. Requirements specification The process of writing donw the user and system requirements in a requirements document.
- 52. Ways of writing a system requirements specification Chapter 4 Requirements Engineering 30/10/2014
- 53. Requirements and design In principle, requirements should state what the system should do and the design
- 54. Natural language specification Requirements are written as natural language sentences supplemented by diagrams and tables. Used
- 55. Guidelines for writing requirements Invent a standard format and use it for all requirements. Use language
- 56. Problems with natural language Lack of clarity Precision is difficult without making the document difficult to
- 57. Example requirements for the insulin pump software system Chapter 4 Requirements Engineering 30/10/2014
- 58. Structured specifications An approach to writing requirements where the freedom of the requirements writer is limited
- 59. Form-based specifications Definition of the function or entity. Description of inputs and where they come from.
- 60. A structured specification of a requirement for an insulin pump Chapter 4 Requirements Engineering 30/10/2014
- 61. A structured specification of a requirement for an insulin pump Chapter 4 Requirements Engineering 30/10/2014
- 62. Tabular specification Used to supplement natural language. Particularly useful when you have to define a number
- 63. Tabular specification of computation for an insulin pump Chapter 4 Requirements Engineering 30/10/2014
- 64. Use cases Use-cases are a kind of scenario that are included in the UML. Use cases
- 65. Use cases for the Mentcare system Chapter 4 Requirements Engineering 30/10/2014
- 66. The software requirements document The software requirements document is the official statement of what is required
- 67. Users of a requirements document Chapter 4 Requirements Engineering 30/10/2014
- 68. Requirements document variability Information in requirements document depends on type of system and the approach to
- 69. The structure of a requirements document Chapter 4 Requirements Engineering 30/10/2014
- 70. The structure of a requirements document Chapter 4 Requirements Engineering 30/10/2014
- 71. Requirements validation Chapter 4 Requirements Engineering 30/10/2014
- 72. Requirements validation Concerned with demonstrating that the requirements define the system that the customer really wants.
- 73. Requirements checking Validity. Does the system provide the functions which best support the customer’s needs? Consistency.
- 74. Requirements validation techniques Requirements reviews Systematic manual analysis of the requirements. Prototyping Using an executable model
- 75. Requirements reviews Regular reviews should be held while the requirements definition is being formulated. Both client
- 76. Review checks Verifiability Is the requirement realistically testable? Comprehensibility Is the requirement properly understood? Traceability Is
- 77. Requirements change Chapter 4 Requirements Engineering 30/10/2014
- 78. Changing requirements The business and technical environment of the system always changes after installation. New hardware
- 79. Changing requirements Large systems usually have a diverse user community, with many users having different requirements
- 80. Requirements evolution Chapter 4 Requirements Engineering 30/10/2014
- 81. Requirements management Requirements management is the process of managing changing requirements during the requirements engineering process
- 82. Requirements management planning Establishes the level of requirements management detail that is required. Requirements management decisions:
- 83. Requirements change management Deciding if a requirements change should be accepted Problem analysis and change specification
- 84. Requirements change management Chapter 4 Requirements Engineering 30/10/2014
- 85. Key points Requirements for a software system set out what the system should do and define
- 86. Key points The requirements engineering process is an iterative process that includes requirements elicitation, specification and
- 87. Key points Requirements specification is the process of formally documenting the user and system requirements and
- 89. Скачать презентацию