Requirements Analysis

Tags

soft-eng

Is the [see page 15, process] of studying user needs to arrive at definitions of system, hardware or software requirements.

This is related to threat modelling.

This involves:

1. [see page 16, Inception]: Identify stakeholders, recognise multiple viewpoints, Q&A. A [see page 17, stakeholders] can be:
   • Persons or organisations who have a valid interest in (or are affected by) the system.
   • Anyone who operates the system.
   • Anyone who benefits from the system.
   • Anyone involved in purchasing or procuring the system.
   • Organisations which regulate aspects of the system.
   • Organisations responsible for system which interface with the system under design.
   • People or organisations opposed to the system.
2. [see page 20, Elicitation]: Collaborate with stakeholders to address:
   • Scope: What is the boundary of the system?
   • Understanding: Users don't know what they want?
   • Volatility: Requirements change over time.
3. [see page 25, Elaboration]: Expand and refine information, consider the 5Ws.
4. [see page 26, Negotiation]: Reconcile conflicts, rank requirements and perform a risk estimation.
5. [see page 28, Specification]: Write-up all that's to be done, develop use cases, UML diagrams and user stories.
6. [see page 40, Validation]: Search for inconsistencies, omissions and errors and then have a technical review with the team.
7. [see page 41, Requirements Management]: Control the change of requirements, tracing them to features, code or subsystems. This involves understanding the relation between requirements.