Various Types of Requirements
Requirement: http://en.wikipedia.org/wiki/Requirement
- Business Requirement: http://en.wikipedia.org/wiki/Business_requirements
- auch Business Case: http://en.wikipedia.org/wiki/Business_case
- User Requirements: http://en.wikipedia.org/wiki/User_requirements_document (user statements)
- Functional Requirement: http://en.wikipedia.org/wiki/Functional_requirements
- * Quality (of Service) Requirement - NFR: http://en.wikipedia.org/wiki/Non-functional_requirements
- Assumptions, Dependencies and Constraints: http://chicwriter.com/2010/11/requirements-gathering-analysis-assumptions-dependencies-constraints/
Rahmen und Randbedingungen
- more Assumptions and Constraints: http://www.bridging-the-gap.com/ba-stories-its-not-all-requirements-assumptions-and-constraints-matter-too/
- Business Constraints: http://docs.oracle.com/cd/E19263-01/817-5759/bus_analysis.html#wp20584
- Typen von Randbedingungen: https://www.projektmagazin.de/glossarterm/randbedingungen
Characteristics of good Requirements
| Characteristic | Explanation |
|---|---|
| Unitary (Cohesive) | The requirement addresses one and only one thing. |
| Complete | The requirement is fully stated in one place with no missing information. |
| Consistent | The requirement does not contradict any other requirement and is fully consistent with all authoritative external documentation. |
| Non-Conjugated (Atomic) | The requirement is atomic, i.e., it does not contain conjunctions. E.g., "The postal code field must validate American and Canadian postal codes" should be written as two separate requirements: (1) "The postal code field must validate American postal codes" and (2) "The postal code field must validate Canadian postal codes". |
| Traceable | The requirement meets all or part of a business need as stated by stakeholders and authoritatively documented. |
| Current | The requirement has not been made obsolete by the passage of time. |
| Unambiguous | The requirement is concisely stated without recourse to technical jargon, acronyms (unless defined elsewhere in the Requirements document), or other esoteric verbiage. It expresses objective facts, not subjective opinions. It is subject to one and only one interpretation. Vague subjects, adjectives, prepositions, verbs and subjective phrases are avoided. Negative statements and compound statements are avoided. |
| Specify Importance | Many requirements represent a stakeholder-defined characteristic the absence of which will result in a major or even fatal deficiency. Others represent features that may be implemented if time and budget permits. The requirement must specify a level of importance. |
| Verifiable | The implementation of the requirement can be determined through basic possible methods: inspection, demonstration, test (instrumented) or analysis (to include validated modeling & simulation). |
User Stories
User Stories: http://en.wikipedia.org/wiki/User_story
"As a <role>, I want <goal/desire> so that <benefit>"
"As a <role>, I want <goal/desire>"
Use Cases
Use Case: http://www.usability.gov/how-to-and-tools/methods/use-cases.html
UML-Diagrams
Possible * Quality Requirements
Sufficient network bandwidth may be a non-functional requirement of a system. Other examples include:
- Accessibility
- Audit and control
- Availability (see service level agreement)
- Backup
- Capacity, current and forecast
- Certification
- Compliance
- Configuration management
- Dependency on other parties
- Deployment
- Documentation
- Disaster recovery
- Efficiency (resource consumption for given load)
- Effectiveness (resulting performance in relation to effort)
- Emotional factors (like fun or absorbing)
- Environmental protection
- Escrow
- Exploitability
- Extensibility (adding features, and carry-forward of customizations at next major version upgrade)
- Failure management
- Fault tolerance (e.g. Operational System Monitoring, Measuring, and Management)
- Legal and licensing issues or patent-infringement-avoidability
- Interoperability
- Maintainability
- Modifiability
- Network topology
- Open source
- Operability
- Performance / response time (performance engineering)
- Platform compatibility
- Price
- Privacy
- Portability
- Quality (e.g. faults discovered, faults delivered, fault removal efficacy)
- Recovery / recoverability (e.g. mean time to recovery - MTTR)
- Reliability (e.g. mean time between failures - MTBF)
- Reporting
- Resilience
- Resource constraints (processor speed, memory, disk space, network bandwidth, etc.)
- Response time
- Robustness
- Safety or Factor of safety
- Scalability (horizontal, vertical)
- Security
- Software, tools, standards etc. Compatibility
- Stability
- Supportability
- Testability
- Usability by target user community
Keine Kommentare:
Kommentar veröffentlichen