Lecture 5 - Managing Requriements Flashcards
Requirements Specification Document Template (IEEE)
REFER TO SLIDES FOR EXAMPLE
What is PEGS?
A way to define requirements, the aim is to execute:
- a Project
- in a certain Environment
- to achieve a certain Goals
- by developing a System
What are the components of Project Book?
P.1 Roles
P.2 Personnel characteristics and constraints
P.3 Imposed technical choices
P.4 Schedule and milestones
P.5 Tasks and deliverables
P.6 Risks and mitigation analysis
P.7 Requirements process and report
What are the components of Environment Book?
G.1 Overall context & goals
G.2 Current situation
G.3 Expected benefits
G.4 System overview
G.5 Limitations and exclusions
G.6 Stakeholders
G.7 Requirements sources
What are the components of Goals Book?
E.1 Glossary
E.2 Components
E.3 Constraints
E.4 Assumptions
E.5 Effects
E.5 Invariants
What are the components of System Book?
S.1 Components
S.2 Functionality
S.3 Interfaces
S.4 Scenarios (use cases, user stories)
S.5 Prioritization
S.6 Verification and acceptance criteria
What is the difference between projects and goals?
- Project Requirements concern how the SW development will be carried out where as,
Goals Requirements capture the business goals of the system why we are building it
What is the difference between the system and the environment?
The system is the objects within the environment whereas the environment is any outside factor that can affect the requirement
What are the sources of requirements?
“Requirements document”
Meeting minutes
PowerPoint presentations
Emails
Regulatory documents
Documentation on previous projects
Code
Competing products
What are the attributes for a good requirement specification?
- Concise
- Complete
- Unambiguous
- Testable
- Consistent
- Feasible
- Modifiable
- Traceable
- Specifies external system behaviour only
- Specifies constraints on the implementation
- Easy to change
- Reference Tool for maintainers
- Records forethought about the life cycle
- Characterises acceptable responses to undesired events
What are the three parts of the requirement analysis framework?
- Functional model: use cases & scenarios
- Static analysis object model: class & object diagrams
- Dynamic model: sequence diagrams
What is the goal of the requirement analysis framework?
Goal is to investigate the problem domain as far as possible before moving to the solution domain (i.e., design & implementation)
What is a UML class diagram?
- A class diagram describes the types of objects in the system and the various kind of static relationships that exist among them.
- Class diagram also show the properties and operations of a class and the constraints that apply to the way objects are connected.
REFER TO SLIDES FOR EXAMPLES
What is multiplicity - in reference to UML class diagram?
The multiplicity of a property is an indication of how many objects may fill the property
What is Class Responsible Collaboration (CRC)?
REFER TO SLIDES FOR EXAMPLES
What is the difference between Analysis and Validation?
- Analysis works with raw requirements as elicited from the system stakeholders
- Validation works with a final draft of the requirements document i.e. with negotiated and agreed requirements
What are the validation outputs?
- Problem list
– List of discovered problems in the requirements document - Agreed actions
– List of agreed actions in response to requirements problems. Some problems may have several corrective actions; some problems may have no associated actions - Management tools for this
– Requirements document with version tracking
– Issue tracking support
What are Requirement Reviews?
A group of people read and analyse the requirements, look for problems, meet and discuss the problems and agree on actions to address these problems
What are the criteria of the review checklist?
- Understandability
– Can readers of the document understand what the requirements mean? - Redundancy
– Is information unnecessarily repeated in the requirements document? - Consistency
– Do the descriptions of different requirements include contradictions? Are there contradictions between individual requirements and overall system requirements? - Organisation
– Is the document structured in a sensible way? Are the descriptions of requirements organised so that related requirements are grouped? - Conformance to standards
– Does the requirements document and individual requirements conform to defined standards? Are departures from the standards, justified? - Traceability
– Are requirements unambiguously identified, include links to related requirements and to the reasons why these requirements have been included?
What are the checklist questions that can be asked?
- Is each requirement uniquely identified?
- Are specialised terms defined in the glossary
- Does a requirement stand on its own or do you have to examine other requirements to understand what it means?
- Do individual requirements use the terms consistently
- Is the same service requested in different requirements? Are there any contradictions in these requests?
- If a requirement makes reference to some other facilities, are these described elsewhere in the document?
- Are related requirements grouped together? If not, do they refer to each other?
What are the 10 test for requirements?
- Does each requirement have a fit criterion that can be used to test whether a solution meets the requirement?
- Is every requirement in the specification relevant to this system?
- Does the specification contain a definition of the meaning of essential terms within the specification?
- Is every reference to a defined term consistent with its definition?
- Is the context of the requirements study wide enough to cover everything we
need to understand? - Does the requirement contain a rationale?
- Have we asked the stakeholders about conscious, unconscious and undreamed of requirements?
- Does the specification contain solutions posturing as requirements?
- Is the stakeholder value defined for each requirement?
- Is each requirement uniquely identifiable?
