Requirements Reference Chapters 5 6 8 CMSC 345
- Slides: 30
Requirements Reference: Chapters 5, 6, & 8 CMSC 345, Fall 2002
Objectives • To introduce the concepts of user and system requirements • To explain functional and non-functional requirements • To present guidelines for writing system requirements • To introduce the concept of use cases for describing functional requirements • To discuss prototyping as a means for requirements elicitation CMSC 345, Fall 2002 2
Requirements Engineering • The process of establishing – the services that the required of the system, – and the constraints under which it operates and is developed • The requirements themselves are the descriptions of the system services and constraints. CMSC 345, Fall 2002 3
Who’s Who? • Client – the person(s) paying for the development and will become the owner of the product • Customer – the person who will buy the product off the shelf (mass marketing), or who has the final say as to whether the product is acceptable (in-house development). May be the same as the client • Stakeholder – Anyone who should have some direct or indirect influence on the system requirements Reference: Mastering the Requirements Process, Robertson and Robertson CMSC 345, Fall 2002 4
Types of Requirements • User requirements – Should describe requirements so that they are understandable by those who do not have detailed technical knowledge. Written mainly for customers (end users) • System requirements – A structured document setting out detailed descriptions of the system services and constraints. Written as a contract between client and contractor • Software specification – A detailed software description that can serve as a basis for a more detailed design. Adds further detail to the systems requirements. Written for developers CMSC 345, Fall 2002 5
Requirements Readers CMSC 345, Fall 2002 6
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. CMSC 345, Fall 2002 7
Functional Requirements • Describe functionality or system services • These services depend on – the type of software being developed – the expected users of the software • Functional user requirements may be highlevel statements of what the system should do, but functional system requirements should describe the system services in detail. CMSC 345, Fall 2002 8
Examples of Functional Requirements (written as user requirements) • The user shall be able to search either all of the initial set of databases or select a subset from it. • The system shall provide appropriate viewers for the user to read documents in the document store. • Every order shall be allocated a unique identifier which the user shall be able to copy to the account’s permanent storage area. CMSC 345, Fall 2002 9
Requirements Imprecision • Problems arise when requirements are not precisely stated • Ambiguous requirements may be interpreted in different ways by developers and clients • Consider the term ‘appropriate viewers’ – Client intention - special purpose viewer for each different document type – Developer interpretation - Provide a text viewer that shows the contents of the document CMSC 345, Fall 2002 10
Requirements Completeness and Consistency • In principle, requirements should be both complete and consistent • Complete – They should include descriptions of all required functionality • Consistent – There should be no conflicts or contradictions in the descriptions of the system functions • In practice, it is impossible to produce a complete and consistent requirements document CMSC 345, Fall 2002 11
Non-functional Requirements • Define system properties and constraints • Examples: – response time – storage requirements – process requirements (e. g. , must use a particular CASE system, programming language, or development method) • Non-functional requirements may be more critical than functional requirements. If one is not met, the system may be useless. CMSC 345, Fall 2002 12
Non-functional Requirements Examples • Product requirement – “It shall be possible for all necessary communication between the APSE and the user to be expressed in the standard Ada character set. ” • Organizational requirement – “The system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95” • External requirement – “The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system” CMSC 345, Fall 2002 13
Goals and Requirements • Non-functional requirements may be very difficult to state precisely. Imprecise requirements are difficult to verify. • Goal – A general intention of the user such as ease of use • Verifiable non-functional requirement – A statement using some measure that can be objectively tested • Goals may be helpful to developers as they convey the intentions of the system users. But all requirements, functional or non-functional, MUST be verifiable. CMSC 345, Fall 2002 14
Example • A system goal – “The system should be easy to use by experienced controllers and should be organized in such a way that user errors are minimized. ” • A verifiable non-functional requirement – “Experienced controllers shall be able to use all the system functions after a total of two hours training. After this training, the average number of errors made by experienced users shall not exceed two per day. ” CMSC 345, Fall 2002 15
Some Requirements Measures CMSC 345, Fall 2002 16
Writing Requirements • Requirements may be written using a natural language (common for user requirements) – Lack of clarity, possibly ambiguous – Requirements confusion • Functional and non-functional requirements tend to be mixed-up – Requirements amalgamation • Several different requirements may be expressed together • Tables and diagrams may help CMSC 345, Fall 2002 17
Example: Editor Grid Requirement 2. 6 Grid facilities To assist in the positioning of entities on a diagram, the user may turn on a grid in either centimetres or inches, via an option on the control panel. Initially, the grid is off. The grid may be turned on and off at any time during an editing session and can be toggled between inches and centimetres at any time. A grid option will be provided on the reduce-to-fit view but the number of grid lines shown will be reduced to avoid filling the smaller diagram with grid lines. CMSC 345, Fall 2002 18
Problems! • Difficult to read • Mixes three different requirements: – Functional requirement (the need for a grid) – Non-functional requirement (grid units) – Non-functional UI requirement (grid switching) CMSC 345, Fall 2002 19
Alternatives to NL Specification CMSC 345, Fall 2002 20
Some Guidelines for Writing Requirements • Invent or find a standard format and use it for all requirements. • Use language in a consistent way. • Use “shall” or “will” for mandatory requirements, “should” for desirable requirements. • Use text highlighting (e. g. , italics) to identify key parts of the requirement. • Do not use vague phrases (e. g. , “around a month, ” “have basic knowledge of”) • Every requirement must be verifiable. • Every requirement should be numbered for traceability. CMSC 345, Fall 2002 21
Use Cases A way of describing a system’s functional requirements • Describes the system’s behavior under various conditions as the system responds to a request from one of the stakeholders called the primary actor. • The primary actor initiates some interaction with the system to accomplish some goal. • The system responds, protecting the interests of the stakeholders. • Different sequences of behaviors (scenarios) can unfold, depending on the request and the conditions surrounding the request. • The use case gathers these scenarios together. CMSC 345, Fall 2002 22
Use Case Format and Example (for this class) Use Case N Use Case: <the name as a short, active verb phrase> Context of Use: <a longer statement of the goal, if needed> Scope: <which system is under discussion> Priority: <scale of 1 (high) to 5 (low)> Level: <one of: summary, user goal, subfunction> Primary Actor: <a role name for the primary actor> CMSC 345, Fall 2002 23
Use Case N Use Case: Print letters Context of Use: User wants to print one or more of the same letter Scope: The Perfect Form Priority: 5 Level: User goal Primary Actor: Faculty member CMSC 345, Fall 2002 24
Stakeholders and Interests: <list of stakeholders and key interests in the use case> Precondition: <what must be true for the use case to proceed> Minimal Guarantees: <how the interests are protected under all exits – worst case situation> Success Guarantees: <what must be true after the user case runs> CMSC 345, Fall 2002 25
Stakeholders and Interests: Faculty member – wants to print letter(s) Precondition: User has opened a form letter Minimal Guarantees: No letters will print and a message stating why will be displayed Success Guarantees: All of the letters will be printed CMSC 345, Fall 2002 26
Trigger: <what starts the use case> Main Success Scenario: <steps from trigger to goal delivery in which nothing goes wrong> CMSC 345, Fall 2002 27
Trigger: Menu selection of “print” Main Success Scenario: 1) User selects “print” 2) A print dialog box appears 3) User changes prints settings 4) User presses “print” 5) The letters print 6) The print dialog box closes CMSC 345, Fall 2002 28
Extensions: <what can happen differently during the scenario> Related Information: <any necessary additional information> CMSC 345, Fall 2002 29
Extensions: 2 a) User has not filled in the custom tags, the date tag, the sender tag, or the return address tag. 2 a. 1) The user will be informed of which tags to specify replacements for. 2 a. 2) The print dialog box will not open. Related Information: None CMSC 345, Fall 2002 30
- Reference node and non reference node
- Reference node and non reference node
- Compsci 345
- Deborah amdur
- Comp345
- Compsci 345
- Me 345
- Comp 345
- A-345-k
- Comp 345
- 345 king william street adelaide
- Comp 345
- Compsci 345
- Comp 345
- Softeng 350
- Softeng 350
- Byk 345
- Test 345
- Bienvenidos himno
- Digital clock in c++ using class
- Cmsc 331
- Cmsc 421
- Cmsc 341
- Cmsc 456 3 cryptology
- Cmsc 250
- Cmsc 331
- Cmsc 203 umbc
- Cmsc 341
- Cmsc 426 umbc
- Cmsc 341
- Cmsc 5707