1 / 40

REQUIREMENTS ENGINEERING

REQUIREMENTS ENGINEERING. What is a requirement?. Descriptions of the services provided by the system and its operational constraints. Reflects the needs of customers for a system. May be… A high level, abstract statement of a service that the system should provide A constraint on the system

umeko
Download Presentation

REQUIREMENTS ENGINEERING

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. REQUIREMENTSENGINEERING

  2. What is a requirement? • Descriptions of the services provided by the system and its operational constraints. • Reflects the needs of customers for a system. • May be… • A high level, abstract statement of a service that the system should provide • A constraint on the system • A detailed formal definiton of a system function.

  3. Requirements engineering • The process of finding out, analysing, documenting and checking these services and constraints.

  4. Types of requirements • User requirements: • high-level abstract requirements • Statements of what services the system is expected to provide and the constraints under which it must operate. • System requirements: • The detailed description of what the system should do • Set out the system’s func., services and operational constraints in detail.

  5. Types of requirements cont. • User requirements may be expanded into several system requirements by adding detail, explaining the services and functions. • Requirements should be written at different levels of detail because of different readers.

  6. Functional and nonfunctional 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.

  7. Functional requirements • Describe the system function in detail, its input and outputs, exceptions etc. • Depends on… • The type of software • The expected users of the software • The specification of the functional requirements should be complete and consistent.

  8. Nonfunctional requirements • May relate to reliability, response time and store occupancy. • Constraints are I/O device capability, system representations, etc. • May specify performance security and availability. So more critical than individual functional requirements. • Failing to meet can mean the whole system is unusable.

  9. Types of nonfunctional requirements • Product req. Specify product behavior • Performance, reliability, portability, usability • Organisational req. • Process standards, implementation, delivery • External req. • Interoperability, legislative, ethical

  10. Examples • Functional requirement: • “The customer must place an order within two minutes of registering.” • Nonfunctional requirement: • “The customer must be able to access their account 24 hours a day, seven days a week.”

  11. Domain requirements • Derived from the application domain and describe system characteristics and features that reflect the domain. • Domain requirements maybe new functional requirements, constraints on existing requirements or define specific computations. • If domain requirements are not satisfied, the system may be unworkable.

  12. Domain requirementsexample • Tolerance level of landing gear on an aircraft (different on dirt, asphalt, water), or what happens to fiber optics line in case of sever weather during winter Olympics (Only domain-area experts know)

  13. 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.

  14. User requirements • Should describe the functional and nonfunctional requirements. • Should only specify the external behavior of the system. • System design characteristics, software jargon, structuredor formal notations, system implementation should be excluded. • Should be written in simple language.

  15. 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.

  16. System requirements • Expanded version of user req. • Describe the external behavior of the system and its operational constraints. • Must not include how the system designed and implemented.

  17. 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.

  18. Structured language specifications • Limits the terminology that can be used and use templates to specify system req. System req. May be specified by: • Using forms • Using tables • Using graphical models

  19. Form-based specifications • Definition of the function or entity. • Description of inputs and where they come from. • Description of outputs and where they go to. • Indication of other entities required. • Pre and post conditions (if appropriate). • The side effects (if any) of the function.

  20. Form based specification example ECLIPSE/Workstation/Tools/DE/FS/3.5.1 Function:Add node Description:Adds a node to an existing design. Inputs: Node type, Node Position Outputs:Design identifier Pre/Post conditions: Other attributes: Definition: ECLIPSE/Workstation/Tools/DE/RD/3.5.1

  21. Structured lang. specification cont. • By using formatted specification variability is reduced and req. are organised more efficiently. • When complex requirements are needed tables or graphical models can be used. • Use tables when there are a number of possible alternative situations. • Use graphical models when you need to show how state changes or describe a sequence of actions.

  22. The requirements document • SRS (software requirement specification) is the official statement of what the system developers should implement • Includes both user requirements and detailed specification of the system requirements.

  23. The requirements document cont. • Has a diverse set of users • the req. document has to be a compromise between communicating the requirement to customers, defining them in precise detail for developers and testers and including information about possible system evolution. • The level of detail depends on the type of system that is being developed and the development process used. • External contractor: very detailed • Iterative development process: less detailed

  24. 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.

  25. Feasibility studies • A feasibility study decides whether or not the proposed system is worthwhile. • Inputs: List of business requirements, system description, how the system improve business • Outputs: Answer of the question “Should we do this development?”

  26. Elicitation and analysis • Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints. • STAKEHOLDER: End-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. • Shortly; people affected by the system directly or indirectly.

  27. Requirements discovery • The process of gathering information about the proposed and existing systems and distilling the user and system requirements from this information. • This information comes from documentation, system stakeholders and the specifications of similar systems.

  28. Registration.boun.edu.tr • Who are stakeholders?

  29. Interviewing • In formal or informal interviewing, the Requirements Engineering team puts questions to stakeholders about the system that they use and the system to be developed. • There are two types of interview • Closed interviews where a pre-defined set of questions are answered. • Open interviews where there is no pre-defined agenda and a range of issues are explored with stakeholders.

  30. Scenarios • Scenarios are real-life examples of how a system can be used. • They should include • A description of the starting situation; • A description of the normal flow of events; • A description of what can go wrong; • Information about other concurrent activities; • A description of the state when the scenario finishes.

  31. Registration scenario

  32. Use cases • Use-cases are a scenario based technique in the UML which identify the actors in an interaction and which describe the interaction itself. • A set of use cases should describe all possible interactions with the system. • Sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system.

  33. Add course Drop course Student Consent Requests Instructor Course scheduling Registration Office Registration use cases

  34. RegsPage Regs system : course Instructor Mypage BOUNsystem Cmpe 352 Ayse Basar Bener Student request request acquired return Add OK Inform available Add available Add Add inform confirm Add CMPE 352

  35. Ethnography • A social scientists spends a considerable time observing and analysing how people actually work. • Social and organisational factors of importance may be observed. • Ethnographic studies have shown that work is usually richer and more complex than suggested by simple system models. • Requirements that are derived from the way that people actually work rather than the way which process definitions suggest that they ought to work. Reality!!! • Requirements that are derived from cooperation and awareness of other people’s activities.

  36. Requirements validation • Concerned to validate that the requirements define the system that the customer really wants. • Requirements error costs are high so validation is very important • Fixing a requirement error before completing project or delivering it is much more cheaper...

  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?

  38. Requirements management • Requirements management is the process of managing changing requirements during the requirements engineering process and system development. • Requirements are inevitably incomplete and inconsistent • There will be always requirements during the process as business needs change and a better understanding of the system is developed; • Different viewpoints have different requirements and these are often contradictory; Students do not want to take courses starting at 09.00am, Instructors do not want to come to school everyday.

  39. 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.

  40. References • Ian Sommerville, Software Engineering • http://www.requirementsauthority.com/functional-and-non-functional.html • http://en.wikipedia.org/wiki/Sequence_diagram • Deriving Tabular Event-Based Specifications from Goal-Oriented Requirements Models - Renaud De Landtsheer, Emmanuel Letier and Axel van Lamsweerde • Bahill A.T. And Dean F.F., Handbook of Systems Engineering and Management

More Related