If you don't get the requirements right, it doesn't matter how well you execute the rest of the project.
Requirements development is a discovery and invention process, not just a collection process.
Change happens. Requirements evolve throughout the project lifecycle.
The interests of all project stakeholders intersect in the requirements process.
Customer involvement is the most critical contributor to software quality.
The customer is not always right, but the customer always has a point.
The first question an analyst should ask about a proposed new requirement is: "Is this requirement in scope?"
Even the best requirements document cannot - and should not - replace human dialogue.
The requirements might be vague, but the product will be specific.
You're never going to have perfect requirements.
These are the top 10 factors that lead to successful software projects, with user involvement being the most critical.
Describe why the organization is implementing the system. High-level
goals.
Example: "Airline wants to reduce airport counter staff costs by 25%."
Goals or tasks users must be able to perform with the product that will provide
value.
Example: "User needs to be able to check-in for flight using airline's
website."
Specify the behaviors the product will exhibit under specific conditions
- what the system does.
Example: "If the Passenger's profile does not
indicate a seating preference, the system shall assign a seat."
Requirements for a product composed of multiple components or subsystems.
Example:
"The airport check-in kiosks need a barcode reader to scan a passport."
Describe how well the product carries out its tasks. Three main categories:
Derived from the application domain. Describe system characteristics reflecting the
domain. May be new FRs or constraints on existing requirements.
Example: "A patient's
designated physician is the only entity allowed to retrieve a patient's medical
reports."
Percentage of time system is up and running correctly.
Formula: MTBF / (MTBF +
MTTR)
MTBF = Mean Time Between Failures; MTTR = Mean Time to Repair
Preventing information loss and protecting correctness of data. No tolerance for errors. Security is sometimes considered a subset of integrity.
Measures: response time, throughput, capacity, latency, usage ratio, number of events processed/denied in a time interval. Usually stated with probabilities and confidence intervals.
Probability the software executes without failure for a specific period. Measured using defect rate, degree of precision for computations.
Ability to cope with unexpected cases - invalid inputs, extreme loads, faults. Measured by: % failures on invalid inputs, degree of service degradation, minimum performance under extreme loads.
Deals with preventing a system from causing injury to people or damage to equipment/environment.
Blocking unauthorized access. Measures: success rate in authentication, resistance to known attacks, time/effort to find a key, % of successful attacks, encryption level, lifespan of passwords/sessions.
Ease of use and training. Sub-measures:
Ability to make changes quickly and cost-effectively. Measured by: mean time to fix a defect, mean time to add functionality, quality/quantity of documentation.
Ability to run under different computing environments (HW, SW, OS, versions). Measured by: number of targeted platforms, proportion of platform-specific components, mean time to port.
Ability to grow to accommodate more users, data, services, geographic locations, transactions, network traffic.
Ability to detect, isolate, and fix defects. Measured by: time to run tests, time to set up testing environment, probability of visible failure in presence of a defect, test coverage.
Ability to make separated components work together. Measured by: mean time to integrate with a new interfacing system.
Ability of existing components to be reused in new applications. Measured by: % of reused requirements/design/code/tests, coupling of components.
Source: Requirements = 56%, Design = 27%, Code = 7%, Other =
10%
Effort to Fix: Requirements defects account for 82% of fix
effort - extremely costly if caught late!
Requirements Engineering is the activity of development, elicitation, specification, analysis, and management of stakeholder requirements, which are to be met by a new or evolving system. A requirement is a statement which translates or expresses a need and its associated constraints and conditions.
Start the process: business need, market opportunity, great idea. Includes business case, feasibility study, system scope, risks.
Requirements discovered through consultation with stakeholders. All tasks involved in discovering and gathering requirements (interviews, document analysis, etc.).
Requirements analyzed, conflicts resolved through negotiation. Develop deeper understanding individually and as a whole (decomposition, conflicts, gaps).
A precise requirements document is produced. Documenting requirements in a well-organized way suitable for the intended audiences.
Requirements document checked for consistency and completeness. Reviewing documented requirements to confirm complete, properly represented, and meets customer needs.
Needs and contexts evolve, and so do requirements. Managing requirements through implementation until project completion (tracing, tracking status, assessing impact).
Person who pays for the software development. Has final word on what the product will be. For internal products = product manager; for consumer market = marketing department.
Person who pays for the software once it is developed. Possibly a user or a business owner buying a product for his employees. Must participate actively in the project.
Users of the current or future system. Experts of current system indicate which functions to maintain/improve. May have special needs (usability, training). Select carefully - different seniority levels.
Expert who knows the work involved. Familiar with the problem the software must solve (e.g., financial expert for finance software, meteorologist for weather systems). Also knows the environment in which the product will be used.
Expert who knows the technology and process. Determines technical and economic feasibility. Estimates cost and time. Educates buyer/client on latest technologies.
Expert in governmental rules and safety relevant to the project. Examples: safety inspectors, auditors, technical inspectors, government inspectors.
Can play the role of the customer for software developed for the general public. Expert who studied the market to determine trends and needs of potential customers.
Familiar with laws and legal aspects. Knows standards relevant to the project.
Document the problem and seek agreement. Ask stakeholders to write a problem statement: What is the problem? Who is affected? What is the impact? Proposed solution? Key benefits?
There is often "a problem behind the problem." Root cause analysis finds underlying causes not immediately apparent. Determine recursively what factors contribute to the problem. Example: "Our ecommerce site is not profitable → Why? → Poor site design? Bad pricing? Poor customer management?"
Create stakeholder profiles including: major value/benefit, likely attitude toward product, major features of interest, known constraints. Ask: Who uses/evaluates/maintains the system? Who is affected by outputs? Who cares (legal/regulatory)?
Product Vision: describes what the product is about and what it could
eventually become.
Project Scope: identifies what portion of the
ultimate vision the current project addresses.
Vision Statement template: "For
[customer] who [need] the [product] is [category] that [benefit] unlike [alternative]
our product [differentiation]"
Sources of constraints:
Includes: Business opportunity, Business objectives and success criteria, Success metrics, Vision statement, Business risks.
Includes major features and dependencies. Describes what the product will do and what it could eventually become.
Includes: Major features for initial and subsequent releases, Scope of initial release, Scope of subsequent releases, Limitations and Exclusions (features NOT included).
Includes: Stakeholder profiles (major value, attitude, features of interest, constraints), Project priorities, Deployment considerations.
Documents all identified risks to the project, helping stakeholders understand what could go wrong and how to mitigate those risks.
Shows all types of external entities that directly interface with the system. No features/functions, from the outside only. Defines system boundary.
Shows all systems related to the system being developed and interactions among them. Includes systems with no direct connection (indirect relationships).
Hierarchically subdivides each feature into further levels of detail. Useful for organizing features in a logical hierarchy.
Identifies external events that could trigger behavior in the system. Events could be triggered by users (user-initiated) or by time (time-triggered).
Stakeholders will not commit to a set of written requirements. Requirements keep changing throughout the project.
Strengths: Get to know domain quickly; interviewees more comfortable
sharing; easier to establish involvement; suitable for busy
executives.
Tips: Acquire background knowledge; prepare questions;
establish rapport; stay in scope; listen actively; suggest ideas.
Common
Mistakes: Not interviewing all right people; asking direct questions too
early; interviewing one-at-a-time; assuming stated needs are exactly correct.
Facilitated structured meetings with selected stakeholders. Requirements elicited from
multiple stakeholders concurrently.
Strengths: Effective in solving
disagreements; suitable for tight schedules.
Tips: Establish ground
rules; plan agenda; stay in scope; use parking lots; timebox discussions; keep team
small but right.
Representative group of users in a facilitated elicitation activity. Useful for exploring
users' attitudes, impressions, preferences, and needs.
Strengths:
Valuable for developing commercial products; highlights consensus and
conflict.
Participants normally don't have decision-making authority.
Get into the trenches and observe specialists in the wild. Shadow important users as they
do their work. Can be silent or interactive.
Strengths: Useful for
high-risk tasks; facilitates requirements validation; identifies new topics for
interviews.
Ethnography also discovers social, human, and political factors.
Strengths: Can reach many people anonymously; asynchronous,
cheap.
Challenges: Preparation time; choice of questions;
statistical significance; validity; getting people to answer.
Question
types: Demography, Attitudinal (Likert scales), Open supplementary,
Redundant for robustness.
Used when much is unknown or to invent new ways of doing things.
Two
phases:
Examining systems to which your system connects. Reveals functional requirements regarding data/service exchange. Consult context diagrams and ecosystem maps to identify systems.
Study existing systems to discover user and functional requirements. Great for getting up
to speed on how an existing system works. Don't have to stick to all features for next
implementation.
Strengths: Suitable for building new versions;
clarifies user input.
Examining existing documentation for potential requirements. Includes user documents, development docs, requirements docs, internal memos, change histories. Often out of date but a good starting point.
Useful when building a new improved version of an existing system. Important to know: what is used/not used/missing, what works/doesn't work, how the system is actually used vs. how it was supposed to be used.
A sequence of interactions between a system and an external actor that results in the actor achieving some outcome of value. A scenario is a specific instance of a use case (specific actor, at specific time, with specific data). Many scenarios can come from a single use case.
Any entity that performs a role in the system (people, organizations, external systems). Drawn as a stick figure. Actors don't interact with other actors. Names should reflect roles rather than actual people.
<<include>>: The base use case always executes the included
use case. Arrow points to the included use case. Represents common functionality needed
in multiple use cases.
<<extend>>: Optionally extends
the base use case. Arrow points to the base use case. Base is meaningful on its own. Can
have extension conditions.
Negative scenarios with goals undesirable from the business perspective. The misactor is
a hostile agent.
Steps: 1) Find misactors → 2) Identify what
misactor would do to harm system (<<threaten>>) → 3) Mitigate
(<<mitigate>>)
Strengths: Elicits security/safety
requirements; early identification of threats.
Risks: May lead to
premature design solutions in step 3.
Low fidelity (static):
Pros: Easy/quick/cheap to build; excellent for
interfaces; encourages creativity; engages users before coding.
Cons: Not
interactive; may not cover all aspects; may seem non-professional.
High
fidelity (functional):
Pros: Deeper understanding of functionality;
reduces design risk; more precise decisions.
Cons: Time-consuming; costly; difficult
to change; false sense of security.
Strengths: Enhances user involvement; closes expectation gaps; resolves
uncertainties early.
Risks: Pressure to release the prototype as
final product; distraction by detail; unrealistic performance expectations; excessive
effort invested.
Contains sufficient detail for those using it to guide their work. Every gap forces designers to guess. Use TBD to flag missing information; resolve all TBDs before implementation.
Error-free. Must accurately describe a capability meeting some stakeholder's need. Check against source materials and subject matter experts. A requirement conflicting with its parent is incorrect.
Contains just the needed information in as few words as possible. Lack of conciseness often caused by compound statements, embedded rationale, or overly complex grammar.
At least one design and implementation exists for it given constraints of time, budget, staff, and environment. Proof-of-concept prototypes can evaluate feasibility.
At least one of: traceable to a stakeholder need, makes product market competitive, establishes a product differentiator, or is dictated by business strategy/standards.
Ranked or ordered according to importance. All requirements compete for limited resources. Should be a collaborative activity involving multiple stakeholders.
Has a single interpretation. Ambiguity depends on reader background. Reduce by defining terms, writing concisely, and testing understanding. Augment with diagrams and tables.
A tester can devise tests to determine whether it was properly implemented. Verification via demonstration, analysis, inspection, or testing. Ambiguous/incomplete requirements are unverifiable.
Does not conflict with any other requirements at any level. Refer to original statements instead of repeating to improve consistency.
Uniquely and persistently identified with a Tag. Can be traced to/from designs, tests, usage models, other artifacts. Enables change impact assessment, coverage analysis, and scope management.
Maintain history of changes; understand connections/dependencies; use unique labels; avoid redundancy; cross-reference related items.
Describing HOW the system achieves something instead of WHAT it should do. Refrain from designing prematurely. Danger signs: naming components, materials, software objects, fields & records in requirements.
Words too vague to be verified. Danger signs: user-friendly, highly versatile, flexible, to the maximum extent, approximately, as much as possible, minimal impact.
Keep each requirement as a single sentence. Conjunction danger signs: and, or, with, also, additionally. Words like "unless," "except," "but" indicate multiple requirements should be split.
Requirements with escape clauses are dangerous because of testing problems. Danger signs: if, but, when, except, unless, although.
Speculation: Vague subjects like usually, generally, often, normally,
typically.
Wishful thinking: Asking for the impossible (100%
reliable, handle all failures, run on all platforms).
Suggestions:
May, might, should, ought, could, perhaps, probably - these are not requirements!
Work through a list: is each requirement "in" or "out"? Keep referring to business objectives. Cut to bare minimum for first release, then revisit "out" requirements for next release.
Assign a prioritized sequence number to each requirement. Make pairwise comparisons between all requirements to judge which has higher priority. Group requirements into features/small sets with similar priorities.
Group requirements into High, Medium, and Low. Consider two measures: importance and urgency. Stakeholders must agree on what each level means. Include priority in SRS. Watch for dependencies between priority levels.
Give stakeholders a hypothetical $100 to allocate among requirements based on priority. Makes prioritization more tangible. Gets groups thinking in terms of resource allocation. Risk: room for cheating/gaming the system.
Used when stakeholders can't agree informally. Features with high risk-adjusted value/cost ratio have highest priority. Feature attractiveness is directly proportional to value and inversely proportional to cost. Participants: PM/BA, customer representative, development representative.
Behavioral UML diagram. Shows actors, use cases, and relationships. 5 relationship types: Association (actor-UC), Generalization (actor), Extend (UC-UC), Include (UC-UC), Generalization (UC). Actors don't interact with each other.
Models interactions between objects in a single use case. Shows order of message exchanges. Components: Lifelines, Activation Bars, Message Arrows (synchronous=solid arrowhead; asynchronous=open), Return messages, Reflexive messages, Sequence Fragments (Alternative=if-else; Option=if; Loop; Reference).
Main building block of OO modeling. Shows objects, attributes, operations, and relationships. Relationship types: Association (logical connection), Multiplicity (cardinality), Aggregation (part-of, open diamond), Composition (strong part-of, filled diamond - parts destroyed with whole), Inheritance/Generalization (is-a relationship, arrow to parent).
Describes dynamic behavior as a flow of activities (workflow). Shows sequence, alternative paths, and parallel flows. Used for modeling processes and workflows.
Depicts states and transitions. Not best for overall progression of events - better for specific state shifts. Used for: event-driven reactive system objects, use case scenarios, object lifecycle behavior.
Used to show business processes, workflows, or system/user interactions. Similar to UML Activity Diagrams. Contains: process steps, transitions, decisions. One of the easiest models for stakeholders to understand.
Takes a functional decomposition approach. Provides a big-picture view of how data moves through a system. Represents systems over a wide range of abstractions. Don't show more than 8 - 10 processes on a single diagram.
3 elements: States (possible system conditions), Transitions (events or conditions causing state changes), Canceled states. Provides brief, complete, and unambiguous representation.
Represents system data relationships. Provides a high-level view of the system. Entity = physical item or collection of data (rectangle, singular noun). Relationship = logical link between pairs of entities. Cardinality shown with numbers/letters (M = many).
Represents user interface design at a high level. Dialog elements as states (rectangles); navigation as transitions (arrows); conditions shown on arrows. Used to represent interactions between an actor and the system in a use case. Helps find missing, incorrect, or unnecessary navigation.
For requirements describing what system should do under all possible combinations of conditions. Factors shown as: statements (true/false), yes/no questions, or questions with more than 2 values. Alternative techniques for representing complex business rules.
Assesses whether a product satisfies customer needs. "Are we building the right product?" Checks the software requirements specification against stakeholders' goals and requirements.
Determines whether the product meets its requirements. "Are we building the product right?" Checks consistency of the SRS artifacts and other development products against the specification.
Validation: "Are we building the right product?" → Against stakeholder
goals.
Verification: "Are we building the product right?" → Against
the specification.
Both must be performed at every stage: elicitation, analysis,
specification.
Various checks using traceability techniques. Developing a traceability matrix. Verify that requirements are well-written according to established criteria.
Excellent for validation by users and customers. More accessible than specification. Demonstrates requirements and helps stakeholders discover problems. Come in all shapes: paper prototypes to formal executable models (horizontal, vertical, evolutive, throwaway).
Derive functional tests from the requirements specification. Each functional requirement should have an associated test. Designing tests may reveal specification errors even before building the system. TDD (Test-Driven Development) begins with tests before programming.
A group reads/analyzes requirements, finds problems, meets to discuss, agrees on action
items.
Informal reviews: desk checks, pass-arounds,
walkthroughs.
Formal reviews / Fagan Inspection: Not more than 2
hours; 3 - 5 reviewers; author presents; metrics collected; supervisor doesn't
participate; moderator leads; all reviewers use checklists; re-inspect if >5% changes.
Formal techniques using modeling paradigms. Tools may provide: completeness checking, consistency checking, refinement checking, model checking, theorem proving.
Can readers of the document understand what the requirements mean?
Is information unnecessarily repeated in the requirements document?
Does the checker know of any missing requirements? Is any information missing from individual requirement descriptions?
Are requirements expressed using clearly defined terms? Could readers from different backgrounds make different interpretations?
Do descriptions of different requirements contain contradictions? Are there contradictions between individual and overall system requirements?
Is the document structured sensibly? Are descriptions organized so related requirements are grouped together?
Does the requirements document conform to defined standards? Are departures from standards justified?
Are requirements unambiguously identified? Do they include links to related requirements and to the reasons why they were included?
Attributes to consider: Priority, Status, Date created, Release number, Validation method used. More complex projects = richer attributes. Many are predefined in RM tools; others defined by requirements engineers per project.
Every requirement must have a unique identification. Most common: requirements numbering by chapter/section. Problems: numbers can't be assigned until document is complete; implicit classification by section may mislead readers.
A requirement is traceable if you can discover: who suggested it, why it exists, what
requirements relate to it, how it relates to
designs/implementations/documentation.
Benefits: Impact analysis,
change control, process monitoring, improved software quality, risk reduction.
Defines links between pairs of elements. For hundreds/thousands of requirements, matrices become large and sparsely populated. Simplified form: maintain lists of related requirement identifiers alongside each requirement description.
Non-modifiable (read-only) version of a document. Describes a moment in time. Enables
document comparison. Comes with a change history. Requires access control.
For
requirements: represents the set of functional and non-functional requirements the
development team committed to implement in a specific release. All changes after
baselining must follow a change control process.
Every version of a requirement needs a unique identifier. Last version must be available to all team members. Changes must be documented and communicated. Requirements documents should include a revision history (changes, dates, by whom, why). Version control tools store and manage revision history.
Steps:
Pros: Easy to use, easy to access, simple training, easy to produce
final document.
Cons: Poor traceability, no status reports, no
granularity, limited search/navigation, poor change management and version control,
simultaneous access issues.
Pros: Good for management, controlled access, links, analysis, reports,
query/navigation, version management, change management.
Cons: Hard
and costly to configure, manage, and use; link between database and final document must
be maintained.
Simplest approach. Prefix indicates requirement type (UC-9, FR-26). Numbers not reused
when a requirement is deleted. Used by commercial RM tools.
Pros:
Easy to retain unique identifier even when moving
requirements.
Cons: No logical/hierarchical grouping; numeric labels
say nothing about intent.
Requirements labeled with section numbers (e.g., 3.2.4.3 is a child of 3.2.4). More
digits = more detailed requirement.
Pros: Simple, compact, familiar;
word processor can auto-assign; supported in RM tools.
Cons: Labels
can grow to many digits; TRAP - word processors don't generate persistent labels
(inserting/moving changes numbers).
Mitigation: Number major
sections hierarchically, then use short text codes with sequence numbers in each
section.
Structured, meaningful tags: e.g., "Print.ConfirmCopies." Unaffected by
adding/deleting/moving other requirements. Unique ID = Parent.Child (e.g.,
Product.Cart.01).
Pros: Avoids maintenance problems of hierarchical
numbers; tags are meaningful.
Cons: Longer and more difficult to
create/maintain uniqueness.
Write as: "The system shall [action] [observable result]" or "The [user class] shall be
able to [do something] [to some object]."
Include optional preconditions and trigger
events. Active voice makes it clear who is taking the action.
More detail when: External client; outsourced development/testing;
geographically dispersed team; testing based on requirements; accurate estimates needed;
traceability required.
Less detail when: Internal work; customers
extensively involved; developers have domain experience; precedents available; package
solution used.
Use "shall" (or "must") to indicate mandatory requirements. Be consistent - pick one word and stick with it. "May" or "should" indicate optional/recommended behavior. "Shall" is a standard signal to developers and testers that implementation is required.
Individuals create value. Without a skilled craftsman, the best tools are useless. Focus on people, not processes.
Heavy processes generate exhaustive documentation with ambiguity and maintenance costs. A single criterion measures progress: working software. Documentation is a support tool, not the goal.
Negotiation protects from financial risk but can cause project failure and endless disputes. Think as one team with a common goal: a successful project.
A predefined plan makes us unresponsive to events. Agile methods are designed to accommodate change, ensuring accurate and adaptive strategic planning.
Possibly a Product Manager or Project Sponsor. Decides features, release date, prioritization, and budget. Has final say on product decisions.
Typically a Project Manager or Team Leader. Responsible for enacting Scrum values and practices. Handles risk management and politics. Keeps everyone productive. Removes impediments.
5 - 10 members. Self-organizing. Cross-functional: QA, Programmers, UI Designers, etc. Membership should change only between sprints.
The project requirements. Prioritized by the Product Owner. Reprioritized at the start of each sprint. Contains all features, enhancements, and fixes needed.
Format: "As a [user role], I want to [goal], so I can [reason]."
Example: "As a user,
I want to log in, so I can access subscriber content."
Captures: Who (user role),
What (goal), Why (reason).
Set of Product Backlog items selected for the Sprint. Created during Sprint Planning. Contains tasks identified and estimated (1 - 16 hours each). Created collaboratively, not by Scrum Master alone.
Displays what work has been completed and what remains. One per developer or work item. Updated every day. Make best guess about hours/points completed each day.
Team selects items from product backlog they can commit to completing. Sprint Backlog created with tasks identified and estimated. Collaboratively done. High-level design considered. Usually a 2-week to 1-month cycle.
Daily, 15 minutes, standing. Not for problem solving. The whole world is invited to observe but only team members, Scrum Master, and Product Owner can talk. Helps avoid unnecessary meetings. 3 questions: What did I do yesterday? What will I do today? Any impediments?
Team presents what it accomplished during the sprint (typically a demo of new features). Informal - 2-hour prep time rule, no slides. Whole team participates. Invite the world.
Team reflects on the process: What went well? What could improve? How to make next sprint better? Results in concrete action items for the next sprint.