Please enable JavaScript.
Coggle requires JavaScript to display documents.
Requirements Quality - Coggle Diagram
Requirements Quality
-
-
Tips
DO's
Use Active Voice rather than Passive Voice
- Upon product upgrade shipment, the serial number will be updated on the contract line [Passive Voice]
- When Fulfilment confirms that they shipped a product upgrade, the system shall update the customer’s contract with the new product serial number [Active Voice]
Focus on straightforward, short, and direct paragraphs.
-
-
-
Be exact at boundary values (e.g. 5 days or fewer) and complex logic (composed of possible outcomes based on a decision taken.)
-
-
-
- Verifiability (Testability)
-
testable requirements are verifiable requirements by using inspections, test, demonstrations and analysis.
-
-
-
- inter-viewpoints: each stakeholder has its own focus and concerns.
- intra-viewpoints: conflicting quality requirements (security/ usability)
Resolve inconsistencies not too soon (to allow further elicitation) or not too late (to allow software development)
Inconsistencies
Types
- Terminology Clash: same concept named differently in different statements (customer or sponsor)
- Designation clash: same name for different concepts in different statements (library user or library user software)
- Structure Clash: same concept structured differently in different statements (Friday or Fri 5pm)
To handle such clashes, use glossary.
Also address these conflict resolution meetings.
Reasons why:
- Personal objectives of stakeholders (should be propagated to requirements level).
- Non-functional conflicting requirements: (performance/safety, confidentiality vs awareness, etc..)
Requirements can be referenced or sourced or originated (stakeholders, business requirements/needs)
Traceability is the ability to trace requirements forward and backward during the development lifecycle.
Traceability Matrix can be used to demonstrate the relationship between requirements and other artifacts.
It used to prove fulfillment of requirements.
- Mandatory (Prioritorzation)
Nice to have requirements should be identified and clearly stated than must have requirements i.e. individual requirements.
-
Volatility means that requirements are always up to changes: addition, deletion or modifications.
Each change is agreed by clients and maintainers.
- The sum of all changes to requirements including new, changed and dropped requirements.
- Often expressed as a percentage of the original number of requirements.
- For example, if there are 20 changes and there were 100 original requirements, requirements volatility is (20/100)*100 = 20%
- Modifiability/ Flexibility
Use effective version control practices and tools to do the following:
- Revision history: changes of the document, who made changes, when it was made and reason.
-
-
Requirements should be feasible according to given, relevant constraints.
Such as costs, benefits, etc..
All relevant requirements (individual, essential, any other type) should be complete.
To deal with Incompleteness or missing requirements
- Use TBD
- Identify who will resolve these requirements
- resolve requirements in next iteration.
- Don't forget to use version control to keep history.
-
Requirements are not correct when they violate:
- Logical Reasoning
- Dependencies
- Legal Requirements
- Possibility of Implementation
Requirements should be adaptive i.e. updated frequently according to changes in the architecture produced.