requirement analysis

Gergő Pintér, PhD

gergo.pinter@uni-corvinus.hu

requirement analysis

Requirement analysis is all about understanding what software is supposed to do and the constraints it must operate within [1].

  • first step of the software development life cycle (SDLC)
  • about understanding the task to avoid costly mistakes

this section is based on [1]

steps of requirement analysis

  1. stakeholder identification
  2. elicitation of requirements (gathering data)
  3. documentation of requirements
  4. analysis and negotiation
  5. validation and verification

1. stakeholder identification

  • not just the customers who commission the software
  • also end users
    • different roles / groups

2. elicitation of requirements

the team actively gathers detailed information about what the software needs to do from the identified stakeholders [1]

  • interviews
    • one-on-one conversations with stakeholders
      to understand their needs
  • questionnaires
    • gather information from a larger group
  • user observation
    • how potential users interact with existing systems
      to identify unspoken needs or problems
    • telemetry

3. documentation of requirements

for who
  • future self
  • colleagues
  • every stakeholder of the project
how
  • searchable
    • organization-wide knowledge sharing (e.g., wiki)
  • version tracked
  • traceable
    • who wrote / edited / approved it

4. analysis and negotiation

reviewing the documented requirements to make sure they are realistic and its implications are understood

  • how difficult will it be to implement?
  • does it conflict with any other requirements?
  • is it actually necessary for the software’s success?

Negotiation comes into play when there are conflicting requirements or limitations in resources like time or budget.
[…]
The goal here is to finalize a set of requirements that is achievable and aligns with the overall objectives of the project. [1]

5. validation and verification

validation
  • is about confirming that the requirements actually meet the needs of the stakeholders
  • are we building the right thing?
  • every stakeholder of the project
verification
  • making sure that the requirements are documented correctly and consistently
    • like proofreading and quality checking
  • to ensure that all requirements are clear, unambiguous, and consistent
  • are we building the thing right?

requirement smells

  • based on the idea of code smells (later in the course)
  • (language based) signs in the requirements that are not necessarily wrong but could be problematic, e.g.,:
    • subjective language
      • “The architecture as well as the programming must ensure a simple and efficient maintainability.”
    • ambiguous adverbs and adjectives
      • “If the (…) quality is too low, a fault must be written to the error memory.”
    • non-verifiable terms
      • “The system may only be activated, if all required sensors (…) work with sufficient measurement accuracy.”

examples from [2]

requirement analysis document example

contents

  • introduction
  • stakeholder identification
  • methodology
  • detailed requirements
    • functional requirements
    • non-functional requirements
  • data flow diagrams or models
  • prioritization of requirements
  • constraints and assumptions
  • acceptance criteria (DoD)
  • appendices
  • version history and approvals
  • it is a living document
  • often updated throughout the project
    as new information becomes available or requirements evolve
  • its main goal is to provide a clear, detailed, and agreed-upon set of requirements that guide the software development process

functional and non-functional requirements

functional requirements define what a system is supposed to do
and non-functional requirements define how a system is supposed to operate [3]

functional

  • features
  • the webserver can serve pages via HTTP2

non-functional

  • quality goals, quality of service requirements
  • webserver is available 99.9% of time
    (yearly about 8h 41m downtime)
  • can serve at least 5.000 queries per sec

more examples on Wikipedia

dependencies

dependencies within a software

  • dependencies between the software components are not always obvious
    • and change over time
  • the core functionalities should be determined at the start of the project
    • that can serve as a foundation for the rest of the software
    • this requires comprehensive understanding of the project
      • requirement analysis

minimum viable product

a new product or service is created with the minimum features necessary to satisfy early adopters and gather feedback for future development

minimum viable product

based on Making sense of MVP (Minimum Viable Product) by Henrik Kniberg

social media platform - example

social media platform - example

social media platform - example

social media platform - example

what is a user story?

  • a popular tool in requirements analysis, particularly in agile software development methodologies
  • simple description of a software feature
    • from the perspective of the end user or customer
  • usually recorded on cards or digital tools
  • and are often accompanied by acceptance criteria (DoD),
    • which define the conditions that must be met to be considered complete

as a [type of user], I want to [action/function] in order to [benefit/value]

behaviour-driven development

  • BDD is an extension of Test-Driven Development
    • later in the course
  • using behaviour-driven development (BDD) can help you to turn an idea for a requirement into implemented, tested, production-ready code,
    • as long as the requirement is specific enough that everyone knows what’s going on [4]
  • BDD starts from a user story and focuses on adding the acceptance criteria

the structure of a story

Title (one line describing the story)

Narrative:
As a [role]
I want [feature]
So that [benefit]

Acceptance Criteria: (presented as Scenarios)

Scenario 1: Title
Given [context]
  And [some more context]...
When  [event]
Then  [outcome]
  And [another outcome]...

Scenario 2: ...

taken from [4] by Daniel Terhorst-North | CC-BY 4.0

ATM example

Story: Account Holder withdraws cash

As an Account Holder
I want to withdraw cash from an ATM
So that I can get money when the bank is closed

Acceptance Criteria:

Scenario 1: Account has sufficient funds
Given the account balance is $100
 And the card is valid
 And the machine contains enough money
When the Account Holder requests $20
Then the ATM should dispense $20
 And the account balance should be $80
 And the card should be returned
Scenario 2: Account has insufficient funds
Scenario 3: Card has been disabled
Scenario 4: The ATM has insufficient funds

taken from [4] by Daniel Terhorst-North | CC-BY 4.0

it may be difficult to extract knowledge

  • the scenarios (and tests) may require exact thresholds
  • need to interview domain specialists
  • communication barrier, lack of common dictionary

benefits of requirements analysis

  • clear project scope and objectives
  • improved stakeholder satisfaction
  • reduced development costs and time
  • enhanced product quality
  • better risk management
  • facilitates prioritization
  • improved communication and collaboration

requirements analysis techniques

  • user stories and user story mapping
  • gantt charts
  • flowcharts
  • data flow diagram
  • etc.

gantt chart

  • project management tool
  • illustrates a project schedule
  • practical to construct the schedule from the deadline and go backward

flowchart

  • represents a workflow or process
  • diagrammatic representation of an algorithm, a step-by-step approach to solving a task
  • ISO 5807
    • published in 1985
    • last reviewed in 2019
  • Wikipedia / Flowchart

flowchart example

a code review process

references

[1]
A. Krysik, “SDLC guide: Requirement analysis in software engineering.” https://stratoflow.com/requirements-analysis , 24-Nov-2023.
[2]
H. Femmer, D. M. Fernández, S. Wagner, and S. Eder, “Rapid quality assurance with requirements smells,” Journal of Systems and Software, vol. 123, pp. 190–213, 2017.
[3]
Wikipedia contributors, “Non-functional requirement — Wikipedia, the free encyclopedia.” https://en.wikipedia.org/w/index.php?title=Non-functional_requirement&oldid=1245895117, 2024.
[4]
D. Terhorst-North, “What’s in a story?” https://dannorth.net/whats-in-a-story , 11-Feb-2007.