Requirements Analysis
Requirements Analysis
"It will not be possible to perfectly satisfy the requirements of every stakeholder, and it is the software engineer’s job to negotiate tradeoffs that are both acceptable to the principal stakeholders and within budgetary, technical, regulatory, and other constraints. A prerequisite for this is that all the stakeholders be identified, the nature of their “stake” analyzed, and their requirements elicited."
SWEBOK Chapter 1 Section 4 Requirements Analysis
This topic is concerned with the process of analyzing requirements to
detect and resolve conflicts between requirements;
discover the bounds of the software and how it must interact with its organizational and operational environment;
elaborate system requirements to derive software requirements.
Requirements analysis wikipedia
Requirements Classification
Requirements can be classified on a number of dimensions. Examples include the following:
Whether the requirement is functional or nonfunctional
Whether the requirement is derived from one or more high-level requirements or an emergent property, or is being imposed directly on the software by a stakeholder or some other source.
Whether the requirement is on the product or the process. Requirements on the process can constrain the choice of contractor, the software engineering process to be adopted, or the standards to be adhered to.
The requirement priority. The higher the priority, the more essential the requirement is for meeting the overall goals of the software. Often classified on a fixed-point scale such as mandatory, highly desirable, desirable, or optional, the priority often has to be balanced against the cost of development and implementation.
Conceptual Modeling
Several kinds of models can be developed. These include use case diagrams, data flow models, state models, goal-based models, user interactions, object models, data models, and many others. Many of these modeling notations are part of the Unified Modeling Language (UML). Use case diagrams, for example, are routinely used to depict scenarios where the boundary separates the actors (users or systems in the external environment) from the internal behavior where each use case depicts a functionality of the system.
UML - Standard Diagrams tutorialspoint
Architectural Design and Requirements Allocation
The point at which the requirements process overlaps with software or systems design.
The process of analyzing and elaborating the requirements demands that the architecture/design components that will be responsible for satisfying the requirements be identified.
Architectural design is closely identified with conceptual modeling.
Requirements Negotiation
AKA "conflict resolution"
Resolving problems with requirements where conflicts occur between two stakeholders requiring mutually incompatible features, between requirements and resources, or between functional and nonfunctional requirements, for example.
Requirements prioritization is necessary.
Consider the ACM Code of Ethics in relation to the requirements (especially the first four principles). There might be conflict between the business and the public. "All people are stakeholders."
Formal Analysis
The formal expression of requirements requires a language with formally defined semantics.
Formal methods wikipedia
Resources
Software Requirements Third Edition Chapter 16: First things first: Setting requirement priorities
MITRE Analyzing and Defining Requirements
