User Requirements

User requirements are known as "stakeholder requirements" in the Business Analysis Body of Knowledge (BABOK).
Development of user requirements starts with understanding of user needs. User needs are the business needs of people doing work. These needs might be the fundamentals needed to actually perform their work. For example, "I need a key to open the door and secure it again after I pass through". The user requirement here is simply the need for a key to the door.
Most people have the basics things they need to do their work so more typically a list of more complicated user needs will be developed into user requirements to describe changes the workers would like to have to perform their jobs more effectively and efficiently. For example, "I would like the door recognize me and open when I need to pass through and then secure itself after I am safely passed it". Most often user needs represent business problems that need to be solved and thus become the basis for user requirements.

A Business Analyst will identify and document user requirements in strict business terms using the vocabulary of the people doing the work. Technical terms are typically avoided since they might steer toward a solution that might not be the best one for solving the business problem. It is better to say that "We need a way to move twenty adults queued in the far parking lot to the main entrance or back in less than 5 minutes and do this every 10 minutes" than to say "We need a bus, tram, or a moving sidewalk". The latter are potential solutions and should be presented as such in a proposal with their attended costs, risks and benefits.
The Business Analyst might start with a list of user requirements to work with for development of justifications and presentation as proposals for management approval. Using a list keeps things simple and it is more efficient for identifying which business needs will be worked and which will not. Often, a list of user requirements will tie together as a project to solve a larger business need.

Later in the user requirements documentation process the Business Analyst might expand and elaborate to provide more details by developing user stories or use cases. User stories are a simple paragraph or two describing how the work might be accomplished when the solution is implemented to resolve the user requirement. Use Cases go into deeper details and will include scenarios describing the future workflow, decision points, and business rules used to make each decision. Both techniques are in common use for elaborating user requirements and presenting them for a solution designer to work from.

A proven technique for successfully documenting user requirements is to involve the people who actually do the work being examined and working with them to help them describe their user needs in terms that accurately depict what is needed and then work to brainstorm, storyboard, and document the best solutions for resolving each of their user needs. Note that much like other things in life, as one user need is resolved others will seem to appear. A skilled Business Analyst can work with people to visualize the future state of performing their work after their immediate user needs are resolved and help to uncover the next level of needs and also resolve those as part of the same project.

Main Menu

See Also

Main Menu