User Requirement

Something that is gathered as part of a software development project. Not necessarily the driving force behind the development project, nor even what gets implemented. UserRequirements might be gathered by a SystemAnalyst or SoftwareArchitect, and may consist of UserStories or result in a RequirementsDocument. Some folks believe there is an inherent FallacyOfRequirements, in that the people who provide the requirements lack sufficient vision to determine how the software should be built and delivered.

(Sorry to interject, but as far as I can tell, the PromptingStatement of FallacyOfRequirements is not the position that "the people who provide the requirements lack sufficient vision to determine how the software should be built". What FallacyOfRequirements says is that there is no such thing as the requirements : instead, the customer (or the users) will tell different stories about what the software should do over the life of a project.)

Okay, there's a war between those that think that UsabilityComesFirst? and the ClientIsTheUser? and those that think UsersProvideJobs? for software developers, but we software developers know best how to make computer technology best serve our corporations. TopDownDesign or BigDesignUpFront versus Xp design, in short.

Not to be confused with FunctionalRequirements or DesignSpecifications? or, indeed, BusinessRequirements

NOTE: This page should be eliminated as redundant after being merged into the larger discussion about requirements. We spend too much time fretting over trivia, folks.

One problem of user requirements gathering is the ScopeControl (see ScopeCreep AntiPattern). Here is a quite common recipe in 3 steps.

Step 1: The 4 viewpoints Formalize the UseCases of the 4 big classes of actors:

The end user (or customer),
The functional administrator, usually some guy in the business doing recurring activities using the software,
The technical administrator, primarily the IntegrationTester then the people in charge of running the software in the operations,
The security administrator, the one who runs the authentications and profiles and thinks about data protection.

Once you got a UseCase for the end user, make sure there are corresponding use cases for administrators. Cross-reference all that as much as you can. Present to the users in workshops the use cases that you've deduced from what was expressed in order to make the whole thing bullet-proof. This will ensure that the software to build is configurable and that you don't really have (almost) no holes in the scope (it is good also to have a good BusinessAnalyst).

Step 2: in scope or out of scope Note every UseCase you can and gather them into the in scope package and out of scope package. This can be the basics of the contract between the users and the IT guys. You can also build a release plan quite quickly.

Step 3: Nominal case and error cases For each of the use cases, think about the nominal case and the error cases attached. This can be quite short. The objective is to be able to size.

Not the XP model but it is quite easy to understand and produces good results.

CategoryRequirements