User Requirements - Revision history

wikademia>Dr. Eme at 00:33, 15 August 2009

2009-08-15T00:33:35Z

← Older revision		Revision as of 00:33, 15 August 2009
Line 1:		Line 1:
	~~<!-- Please do not remove or change this AfD message until the issue is settled -->~~
	<!-- The nomination page for this article already existed when this tag was added. If this was because the article had been nominated for deletion before, and you wish to renominate it, please replace "page=User Requirements" with "page=User Requirements (2nd nomination)" below before proceeding with the nomination.
	~~-->{{AfDM\|page=User Requirements\|logdate=2009 August 10\|substed=yes}}~~
	~~<!-- For administrator use only: {{oldafdfull\|page=User Requirements\|date=10 August 2009\|result='''keep'''}} -->~~
	~~<!-- End of AfD message, feel free to edit beyond this point -->~~
	User requirements are known as "stakeholder requirements" in the [[Business Analysis Body of Knowledge]] (BABOK). <ref>{{cite book \|title=A Guide to the Business Analysis Body of Knowledge \|publisher=International Institute of Business Analysis \|location=[[Toronto, ON]] \|year=2009 \|isbn=9780981129211}}</ref>		User requirements are known as "stakeholder requirements" in the [[Business Analysis Body of Knowledge]] (BABOK). <ref>{{cite book \|title=A Guide to the Business Analysis Body of Knowledge \|publisher=International Institute of Business Analysis \|location=[[Toronto, ON]] \|year=2009 \|isbn=9780981129211}}</ref>
	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.		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.

wikademia>Wikademia: 4 revisions

2009-08-11T00:16:54Z

4 revisions

← Older revision	Revision as of 00:16, 11 August 2009
(No difference)

wikademia>Dennisthe2 at 21:42, 10 August 2009

2009-08-10T21:42:42Z

← Older revision		Revision as of 21:42, 10 August 2009
Line 1:		Line 1:
			<!-- Please do not remove or change this AfD message until the issue is settled -->
			<!-- The nomination page for this article already existed when this tag was added. If this was because the article had been nominated for deletion before, and you wish to renominate it, please replace "page=User Requirements" with "page=User Requirements (2nd nomination)" below before proceeding with the nomination.
			-->{{AfDM\|page=User Requirements\|logdate=2009 August 10\|substed=yes}}
			<!-- For administrator use only: {{oldafdfull\|page=User Requirements\|date=10 August 2009\|result='''keep'''}} -->
			<!-- End of AfD message, feel free to edit beyond this point -->
	User requirements are known as "stakeholder requirements" in the [[Business Analysis Body of Knowledge]] (BABOK). <ref>{{cite book \|title=A Guide to the Business Analysis Body of Knowledge \|publisher=International Institute of Business Analysis \|location=[[Toronto, ON]] \|year=2009 \|isbn=9780981129211}}</ref>		User requirements are known as "stakeholder requirements" in the [[Business Analysis Body of Knowledge]] (BABOK). <ref>{{cite book \|title=A Guide to the Business Analysis Body of Knowledge \|publisher=International Institute of Business Analysis \|location=[[Toronto, ON]] \|year=2009 \|isbn=9780981129211}}</ref>
	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.		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.

wikademia>Box2105: added citations

2009-08-10T16:55:08Z

added citations

← Older revision		Revision as of 16:55, 10 August 2009
Line 1:		Line 1:
	{{~~dated prod~~\|~~concern~~ = ~~non-sourced original research~~\|~~month~~ = ~~August~~\|~~day~~ = 10\|year = 2009\|~~time = 15:13\|timestamp~~ = ~~20090810151340~~}}		User requirements are known as "stakeholder requirements" in the [[Business Analysis Body of Knowledge]] (BABOK). <ref>{{cite book \|title=A Guide to the Business Analysis Body of Knowledge \|publisher=International Institute of Business Analysis \|location=[[Toronto, ON]] \|year=2009 \|isbn=9780981129211}}</ref>
	<~~!-- Do not use the "dated prod" template directly; the above line is generated by "subst:prod\|reason" --~~>		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.
	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.		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.
Line 9:		Line 8:
	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.		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.		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. <ref>{{cite book \|title=Writing Effective Use Cases \|publisher=Addison-Wesley \|location=[[Boston, MA]] \|year=2001 \|isbn=0201702258}}</ref> 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.		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.

			==References==
			{{reflist}}

			==External links==
			* [http://www.theiiba.org/am/ International Institute of Business Analysts (IIBA)]

wikademia>Mhking: Proposing article for deletion per WP:PROD. (TW)

2009-08-10T15:13:41Z

Proposing article for deletion per WP:PROD. (TW)

← Older revision		Revision as of 15:13, 10 August 2009
Line 1:		Line 1:
			{{dated prod\|concern = non-sourced original research\|month = August\|day = 10\|year = 2009\|time = 15:13\|timestamp = 20090810151340}}
			<!-- Do not use the "dated prod" template directly; the above line is generated by "subst:prod\|reason" -->
	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.		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.

wikademia>Box2105: Created original page for others to expand on.

2009-08-10T15:11:33Z

Created original page for others to expand on.

New page

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.