Depending on context and purpose requirements can be understood as customary documents, contents, or work in progress.
- Given that requirements are the entry point of engineering processes, nothing should be assumed regarding their form (natural, formal, or specific language), or content (business, functional, non-functional, or technical).
- Depending on the language used, requirements can be directly analyzed and engineered, or may have to be first formatted (aka captured).
- Requirements taxonomy should be set with regard to processes (business or architecture driven) and stakeholders (business units or enterprise architecture).
- Depending on content and context, requirements can be engineered as a whole (agile development models), or set apart as to tally with external dependencies (phased development models).
Further Reading
- Thread
- How to Begin with Requirements
- Focus: Business Analyst Booklet
- Requirements Capture
- Requirements Taxonomy
- Requirements & Architecture Capabilities
- Requirements Analysis
- Requirements Metrics Matter
- Focus: Users’ Stories & Use Cases
- Use Cases
- Non Functional requirements
- Focus: Rules & Architecture
- Requirements Platform
- From Requirements to Function Points
- Focus: Requirements Reuse