requirements:requirements

This is an old revision of the document!

Requirements management

Requirements management is the process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project. A requirement is a capability to which a project outcome (product or service) should conform.

Requirements management is an essential component of the Application Lifecycle Management (ALM) process. It involves gathering requirements from stakeholders, documenting the requirements, tracking changes to the requirements, and ensuring that the requirements are met during software development and testing. The benefits of requirements management in ALM include ensuring that the software application is aligned with the business needs, reducing the risk of errors and delays, improving collaboration and communication among stakeholders, and improving the overall quality of the software application.

  • documenting
  • analyzing
  • tracing
  • prioritizing
  • agreeing

Examples of requirements management:

  • Collecting and documenting software requirements from stakeholders, such as users, customers, and subject matter experts.
  • Analyzing and prioritizing requirements based on their importance, feasibility, and impact on the system.
  • Tracing requirements to ensure that they are implemented correctly and meet the project goals.
  • Managing changes to requirements throughout the development process, including adding new requirements, modifying existing ones, and removing unnecessary ones.
  • Defining test cases and scenarios based on the requirements to ensure that the system meets the expected behavior.
  • Creating and maintaining a requirements management plan that outlines the process, tools, and responsibilities for managing requirements.
  • Tracking requirements using a dedicated requirements management tool, such as JIRA, Trello, or ReqView, to ensure that they are completed on time and within budget.
  • Conducting regular reviews and evaluations of the requirements management process to identify areas for improvement.
  • Communicating requirements and changes to all stakeholders, including developers, testers, project managers, and customers, to ensure that everyone is aligned with the project goals.
  • Ensuring that the requirements are well-defined, clear, and testable, and that they meet regulatory and compliance standards.
  • Non-functional requirement (NFR)
  • Epic - feature - story - task
Snippet from Wikipedia: Requirements management

Requirements management is the process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project. A requirement is a capability to which a project outcome (product or service) should conform.

Creative Commons Attribution-Share Alike 4.0

Agile Requirements

Cone of Uncertainty

Requirements analysis

Snippet from Wikipedia: Requirements analysis

In systems engineering and software engineering, requirements analysis focuses on the tasks that determine the needs or conditions to meet the new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating, and managing software or system requirements.

Requirements analysis is critical to the success or failure of a systems or software project. The requirements should be documented, actionable, measurable, testable, traceable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.

Creative Commons Attribution-Share Alike 4.0

Taxonomy of Requirements

Functional vs non-functional requirments

Information Management Body of Knowledge (IMBOK)


The IMBOK process areas are:
  • Projects: Adding new capacity, software, and hardware to information systems
  • Business Change: Evaluating information to drive improvements in processes
  • Business Operations: The day-to-day of a business. These will guide improvements based on updates to processes, and will hopefully increase benefits.
  • Performance Management: Trying to ensure operations are running at peak capacit


IMBOK.org

Requirements traceability

Snippet from Wikipedia: Requirements traceability

Requirements traceability is a sub-discipline of requirements management within software development and systems engineering. Traceability as a general term is defined by the IEEE Systems and Software Engineering Vocabulary as (1) the degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or primary-subordinate relationship to one another; (2) the identification and documentation of derivation paths (upward) and allocation or flowdown paths (downward) of work products in the work product hierarchy; (3) the degree to which each element in a software development product establishes its reason for existing; and (4) discernible association among two or more logical entities, such as requirements, system elements, verifications, or tasks.

Requirements traceability in particular, is defined as "the ability to describe and follow the life of a requirement in both a forwards and backwards direction (i.e., from its origins, through its development and specification, to its subsequent deployment and use, and through periods of ongoing refinement and iteration in any of these phases)". In the requirements engineering field, traceability is about understanding how high-level requirements – objectives, goals, aims, aspirations, expectations, business needs – are transformed into development ready, low-level requirements. It is therefore primarily concerned with satisfying relationships between layers of information (aka artifacts). However, traceability may document relationships between many kinds of development artifacts, such as requirements, specification statements, designs, tests, models and developed components. For example, it is common practice to capture verification relationships to demonstrate that a requirement is verified by a certain test artifact.

Traceability is especially relevant when developing safety-critical systems and therefore prescribed by safety guidelines, such as DO178C, ISO 26262, and IEC61508. A common requirement of these guidelines is that critical requirements must be verified and that this verification must be demonstrated through traceability.

Creative Commons Attribution-Share Alike 4.0

Disciplines & Methodologies

Tools & Technologies

Links

External links:

, , ,
  • requirements/requirements.1679735892.txt.gz
  • Last modified: 2023/03/25 09:18
  • by Henrik Yllemo