user-needs
Line-by-line Instructions
- Agreed Goals
- This should be a summary of product goals agreed to by both
users and developers. You might have a draft of this at the
beginning of the project if you were given a problem statement by
the customer. More likely, you would arive at this statement after
you have completed requirements gathering. In either case, you
might revise this statement as you learn the details of the problem
and work through your solution. You should not have to revise it
often, because details are best tracked in the use cases and feature
specifications.
- What is the system's business environment?
- A "business environment" is the overall business setting in
which the system will be used. Describe who will use the system,
the organization where those users work, who they work with, and
which business processes the system affects.
- What is the system's physical environment?
- Describe where the server will be located. And, describe where
users will be located. Briefly note the physical characteristics of
these environments affect the system's performance or
usability.
- What is the system's technology environment (hardware and
software)?
- Decribe the hardware and software that the system depends on, or
interoperates with. Note compatability features that users expect.
- Stakeholders / Actors
- Start by listing different types of stakeholders and users. Use
the greater-than notation to indicate subtypes of stakeholders and
users. Then, come back to describe each class of stakeholder / user
in detail. Use the sample text to prompt you to think of details
and key needs of each class of stakeholder. As you go, make a note
of key needs of that all stakeholders have in common. Review your
interview and brainstorming notes and user stories to get more
ideas.
- Notes from Interviews and Brainstorming
- Link to interview notes, notes from brainstorming meetings, or
other sources of information on user needs.
- User Stories
- Write a few user stories to sketch out how users could use the
system. User stories should be very short, simple, and concrete.
- Performance and Capacity Needs
- If potential customers or users have stated performance or
cacpacity needs, capture that here. These will be reconciled with
other user needs and development team priorities when the SRS is
written.
|
Advice from other
ReadySET Users
- To add your own words of wisdom, please send an email to the ReadySET Pro users mailing
list.
- HEADLINE
- BODY OF ADVICE
Further Reading
|
|