ICS 125: Requirements Concerns & Approaches
Why Do We Need Requirements?
- Make everyone on the team share the same understanding of what they are trying to build
- Feeds information into all other project documents and the system design
- Allow early validation of proposed features, before effort is
spent designing and implementing them
- Define exactly what the test cases should verify
- Serve as a contract between development team and the customer
What do Requirements Specify?
- Goal of the system (may be a subset of the goals of the
project)
- Gather and capture your understanding of user needs
- Who are the users? (sometimes customer != user)
- User stories or Use cases
- Estimates on needed performance and scalability. Limits on hardware capacity
- Domain model: ontology, common processes, etc.
- Document safety concerns (e.g., we will never show personal
information to other users, the plane should never crash)
- Precisely state your approach to addressing those needs
- Features that your system will provide
- List the complete feature set
- Describe how features will address user needs
- Exactly what data is processed/stored and what it means
- Exactly how will the system behave
- "Sketches" of the desired system:
- Mockups
- Use cases describing the expected interaction between system and user
- Pragmatic or external constraints on this system. E.g.:
- UI design must satisfy section 508 rules
- It will have unit tests in JUnit
- Document simplifying assumptions
- Goals for each important quality: e.g., performance, defects, robustness
- Constraints on the design (e.g., we cannot use dialog boxes on
a cell phone display)
Where do Requirements Come From?
- Directly from customers or end users
- Business people inside your company (e.g., marketing and sales)
- Other groups inside your company (e.g., technical support, operations)
- Competitive features offered by other vendors
- Government regulation, industry standards
- Technical constraints stemming from other software components
- The ideas of the developers and their management
- Based on your own experience as users, or from supporting users
Approaches > User stories
- A user story is just a short narrative paragraph describing how
the user uses the system to achieve a goal.
- User stories are higher level and less precise than use cases
- User stories can be written more quickly and earlier than use
cases. Then, they can be refined into use cases later.
- Many methodologies have suggested "narratives". Kent Beck's XP methodology makes
user stories the main form of requirements and equates them with
tasks (units of development work). In XP:
- The customer or a customer surrogate writes the stories, and
developers estimate the effort needed for each
- The drawback to using user stories alone is that they are too
high-level, incomplete, and ambiguous.
- Some ambiguity can be removed through clearly written English
- Example
- A good user story captures an aspect of user's needs. This
helps with understanding and validation. And, it can lead to more
precise requirements later.
Approaches > Use Cases
- "Use cases" were popularized by Ivar Jacobson's Objectory
methodology, and later became 1/3 of UML
- Detailed enough to allow for validation
- Simple and concrete enough that non-technical stakeholders can contribute
- A use case is a sequence of steps that an actor (e.g., a user)
follows to achieve a specific goal.
- Actors can also refer to external programs that access your
system.
- The steps are fairly precise, but should not make commitments
to particular low-level design decisions
- Use cases are not pseudo-code: don't try to program all
possible interactions, just make one possible sequence very clear
and note alternatives.
- A use case diagram relates actors to use cases, and use cases to
other use cases, and actors to other actors, and defines the system
boundary.
- Use case contents:
- Unique ID
- Name
- Purpose/Summary
- Actor(s) (who does this use case)
- Stakeholder interests
- Preconditions
- Steps in main success scenario
- Extensions/Variations
- Example
- A good use case is useful for both validation and suggests
specific test cases for later verification.
Approaches > Feature Specifications
- List the features that the system will provide, and describe each one in detail.
- Describe each feature with screenshots, narratives, formulas,
tables, state machines, flowcharts, etc. Document inputs and
outputs. Use whatever fits the feature.
- Include external interfaces (i.e. APIs) that the system
provides.
- Example
- A good feature specification is useful in validation, construction, and verification
Approaches > Mockups
- Quickly build a "sketch" of the way that the UI will work.
- Basic metaphors
- Screen flow
- Information on each screen
- How would users carry out the steps of a use case?
- NOT the precise look and feel
- Mockups do not need to actually work, they just need to
demonstrate ideas
- Example
- A good mockup is useful in validation, construction, and verification
Approaches > More Formal Specifications
- State machines
- Algebraic specifications
- Decision tables
- Decision trees
sample use cases templateexample software testing plan templateProject plan template