Difference between revisions of "Requirement"

From CNM Wiki
Jump to: navigation, search
(→‎Functional (solution))
 
(156 intermediate revisions by 2 users not shown)
Line 1: Line 1:
−
A [[requirement]] is an expressed demand, desire, expectation, and/or wish to have or not to have a certain capability, condition, feature, and/or property. The term, [[requirements]], may refer to the aggregate of various ''requirements'' that are approved, verified, and/or validated by the [[product owner]] or another authority for the ''requested product''. Those ''requirements'' that limit the [[product]]'s or [[process]] of the production's capabilities and/or conditions are called [[constraint]]s.
+
A [[requirement]] is an expressed demand, desire, expectation, and/or wish to have or not to have a certain [[market exchangeable]] and/or a certain capability, condition, feature, and/or property. The plural term, [[requirements]], may refer to the aggregate of various ''requirements'' that the [[product owner]] or another authority for the ''requested product'' and/or its development [[process]] has approved, verified, and/or validated. Those ''requirements'' that limit the [[market exchangeable]]'s or [[process]] of the production's capabilities and/or conditions are called [[constraint]]s.
  
  
 
==Definitions==
 
==Definitions==
 +
According to the [[ INCOSE Systems Engineering Handbook (4th edition)]],
 +
:[[Requirement]]. A statement that identifies a system, product, or process characteristic or constraint, which is unambiguous, clear, unique, consistent, stand‐alone (not grouped), and verifiable, and is deemed necessary for stakeholder acceptability.
  
−
===Common-style===
+
===Common definitions===
 
:The common-style definitions particularly include:
 
:The common-style definitions particularly include:
 
:*[[Requirement]]. Something that you must do, or something you need ([[Cambridge Dictionary]]).
 
:*[[Requirement]]. Something that you must do, or something you need ([[Cambridge Dictionary]]).
 
:*[[Requirement]]. Something required such as (a) something wanted or needed or (b) something essential to the existence or occurrence of something else ([[Merriam-Webster]]).
 
:*[[Requirement]]. Something required such as (a) something wanted or needed or (b) something essential to the existence or occurrence of something else ([[Merriam-Webster]]).
  
−
===Engineering-style===
+
===Engineering definitions===
 
:According to the [[Rational Unified Process]] ([[Rational Unified Process|RUP]]), which is an iterative software development process framework that [[IBM]] markets,
 
:According to the [[Rational Unified Process]] ([[Rational Unified Process|RUP]]), which is an iterative software development process framework that [[IBM]] markets,
 
::A [[requirement]] describes a condition or capability to which a system must conform; either derived directly from user needs, or stated in a contract, standard, specification, or other formally imposed document.
 
::A [[requirement]] describes a condition or capability to which a system must conform; either derived directly from user needs, or stated in a contract, standard, specification, or other formally imposed document.
Line 19: Line 21:
  
 
:The [[IEEE Standard Glossary of Software Engineering Terminology]] defines a ''requirement'' similarly to the two definitions above.
 
:The [[IEEE Standard Glossary of Software Engineering Terminology]] defines a ''requirement'' similarly to the two definitions above.
 +
 +
According to the [[BABOK Guide|BABOK Guide (3rd edition)]],
 +
:[[Requirement]]. A usable representation of a need.
 +
 +
===Stakeholder definitions===
 +
:From a [[stakeholder]] perspective, a [[requirement]] is anything that helps:
 +
:#'''Customers''' to describe what they wish to obtain;
 +
:#'''Suppliers''' to understand what the customer wants;
 +
:#'''Requirements staffers''' to substantively develop requirements blueprints for their own organizations, as well as other [[requirements document]]s such as requirements quality checklists, requirements creator's handbooks, etc.
  
 
==Applications==
 
==Applications==
Line 27: Line 38:
 
:*The [[International Institute of Business Analysis]] ([[International Institute of Business Analysis|IIBA]]) develops their [[A Guide to the Business Analysis Body of Knowledge]] ([[A Guide to the Business Analysis Body of Knowledge|BABOK Guide]]). The [[Certified Business Analysis Professional]] ([[Certified Business Analysis Professional|CBAP]]) certification that [[International Institute of Business Analysis|IIBA]] develops is based on that body of knowledge.
 
:*The [[International Institute of Business Analysis]] ([[International Institute of Business Analysis|IIBA]]) develops their [[A Guide to the Business Analysis Body of Knowledge]] ([[A Guide to the Business Analysis Body of Knowledge|BABOK Guide]]). The [[Certified Business Analysis Professional]] ([[Certified Business Analysis Professional|CBAP]]) certification that [[International Institute of Business Analysis|IIBA]] develops is based on that body of knowledge.
 
:*The [[United States Department of Defense]] ([[United States Department of Defense|DOD]]) utilizes its own standards, which are largely derived from the [[Institute of Electrical and Electronics Engineers|IEEE]] standards.
 
:*The [[United States Department of Defense]] ([[United States Department of Defense|DOD]]) utilizes its own standards, which are largely derived from the [[Institute of Electrical and Electronics Engineers|IEEE]] standards.
 +
 +
===New product development===
 +
:''Requirements'' for the [[market exchangeable]]s to be designed, developed, and delivered are in the core of [[new product development]]. [[Hewlett-Packard]] developed the [[FURPS]] system, which is quite popular in the software development and particularly promoted by [[IBM]]. The [[Agile methodology|Agile methodologi]]es widely use product ''requirements'' in forms of [[user story]], [[epic story]], and so on.
  
 
===Procurement===
 
===Procurement===
−
:''Requirements'' for the [[product]]s to be purchased are in the core of [[procurement]]. Forms of the procurement ''requirements'' range from oral statements such as ''I would like to buy the cheapest soap you carry'' and up to [[procurement statement of work|procurement statements of work]], [[business case]]s, etc.
+
:''Requirements'' for the [[market exchangeable]]s to be purchased are in the core of [[procurement]]. Forms of the procurement ''requirements'' range from oral statements such as ''I would like to buy the cheapest soap you carry'' and up to [[procurement statement of work|procurement statements of work]], [[business case]]s, etc.
−
 
 
−
===Product development===
 
−
:''Requirements'' for the [[product]]s to be designed, developed, and delivered are in the core of [[product development]]. [[Hewlett-Packard]] developed the [[FURPS]] system, which is quite popular in the software development, particularly by [[IBM]]. The [[Agile methodology|Agile methodologi]]es widely use product ''requirements'' in forms of [[user story]], [[epic story]], and so on.
 
  
 
===Project management===
 
===Project management===
Line 47: Line 58:
 
:*The [[International Council on Systems Engineering]] ([[International Council on Systems Engineering|INCOSE]]) leads endeavors to systematize practices related to ''requirements'' and develops their body of knowledge. The systems engineering professional certifications that [[International Council on Systems Engineering|INCOSE]] develops is based on that body of knowledge.
 
:*The [[International Council on Systems Engineering]] ([[International Council on Systems Engineering|INCOSE]]) leads endeavors to systematize practices related to ''requirements'' and develops their body of knowledge. The systems engineering professional certifications that [[International Council on Systems Engineering|INCOSE]] develops is based on that body of knowledge.
  
−
==Conventionally-accepted taxonomies==
+
==Natural classifications==
−
===Product vs process===
+
===Categorized by audiences===
−
:With regard to its nature, a ''requirement'' may refer to:
+
:''Requirements'' developers develop ''requirements''. There two major pairs of audiences that primarily consume those ''requirements'':
−
:*[[Product requirement]] that indicates specific feature, functionality, and/or qualities of the requested [[product]];
+
:#''Customer and contractor'' when the ''requirements'' are needed to understand or confirm what needs to be done and, possibly, how what needs to be done would be done.
−
:*[[Transition requirement]] that indicates specific ways of the ''requested product's'' design, development, delivery, and/or collection of feedback.
+
:#''Contractor's management and implementing staffers'' when a set of ''requirements'' needs to be bettered and/or broken-down in order to be implemented by a contractor's team and/or subcontractors. This type of ''requirements'' is often called [[technical requirement]]s.
  
 
===Categorized by imposing party===
 
===Categorized by imposing party===
 
:Any '''requirement''' can be imposed by one or more of the following three:
 
:Any '''requirement''' can be imposed by one or more of the following three:
−
:#[[Customer]];
+
:#[[Customer]], who states what is needed to be solved and, possibly, how what needs to be solved should be solved;
−
:#[[Contractor]];
+
:#[[Contractor]], who has its own circumstances, both resources and limitations;
 
:#[[Third party]] such as:
 
:#[[Third party]] such as:
 
:#*Government of any level including federal/national authorities such as the [[Internal Revenue Service]] ([[Internal Revenue Service|IRS]]) and [[Environmental Protection Agency]] ([[Environmental Protection Agency|EPA]]), regional authorities, and municipalities. This type of ''requirements'' may be called [[regulatory requirement]]s.
 
:#*Government of any level including federal/national authorities such as the [[Internal Revenue Service]] ([[Internal Revenue Service|IRS]]) and [[Environmental Protection Agency]] ([[Environmental Protection Agency|EPA]]), regional authorities, and municipalities. This type of ''requirements'' may be called [[regulatory requirement]]s.
Line 63: Line 74:
 
:Some ''requirements'' are originated from the sources such as [[demographics]], [[economy]], and [[geography]] that are outside of those three, but they need to be brought to the [[operations]] or [[project]] by one of those three.
 
:Some ''requirements'' are originated from the sources such as [[demographics]], [[economy]], and [[geography]] that are outside of those three, but they need to be brought to the [[operations]] or [[project]] by one of those three.
  
−
==Competing taxonomies==
+
===Categorized by progress===
 +
:''Requirements'' can be categorized based on their state in the [[requirement lifecycle]]:
 +
:#'''[[Stated requirement]]'''. A requirement articulated by a stakeholder that has not been analyzed, verified, or validated. Stated requirements frequently reflect the desires of a stakeholder rather than the actual need.
 +
:#[[Confirmed requirement]].
 +
:#[[Prioritized requirement]].
 +
:#[[Organized requirement]].
 +
:#[[Modeled requirement]].
 +
:#'''[[Verified requirement]]'''. Requirements that have been shown to demonstrate the characteristics of requirements quality and as such are cohesive, complete, consistent, correct, feasible, modifiable, unambiguous, and testable.
 +
:#'''[[Validated requirement]]'''. A requirement that has been demonstrated to deliver business value and to support the business goals and objectives.
 +
:#[[Reviewed requirement]].
 +
:#[[Approved requirement]].
 +
:#[[Implemented requirement]].
 +
 
 +
===Product vs process===
 +
:With regard to its nature, a ''requirement'' may refer to:
 +
:*[[Product requirement]] that indicates a specific [[capacity]], condition, feature, functionality, and/or quality of the requested [[market exchangeable]];
 +
:*[[Transition requirement]] ([[process requirement]], [[project requirement]]) that indicates one or more specific ways of the ''requested product's'' design, development, delivery, and/or collection of feedback.
 +
 
 +
==Modeled classifications==
 
Because of the variety of research frameworks, a few competitive taxonomies exist.
 
Because of the variety of research frameworks, a few competitive taxonomies exist.
  
−
===IEEE-developed taxonomy===
+
===IIBA-marketed taxonomy===
−
 
 
−
===IIBA-developed taxonomy===
 
 
:Particularly through their [[A Guide to the Business Analysis Body of Knowledge|BABOK Guide]], the [[International Institute of Business Analysis|IIBA]] markets the following taxonomy:
 
:Particularly through their [[A Guide to the Business Analysis Body of Knowledge|BABOK Guide]], the [[International Institute of Business Analysis|IIBA]] markets the following taxonomy:
 
:#'''[[Business requirement]]'''. The highest level of the the [[International Institute of Business Analysis|IIBA]]'s hierarchy of ''requirements''. [[Business requirement]] is a business rationale for one or more changes that, when implemented, will permit the organization to increase revenue, avoid costs, improve service, or meet [[regulatory requirement]]s. The rationale commonly includes the organizational goals, objectives, and needs; it usually describes opportunities that an organization wants to realize or problems that they want to solve. A [[business case]] is the common form of a [[business requirement]].
 
:#'''[[Business requirement]]'''. The highest level of the the [[International Institute of Business Analysis|IIBA]]'s hierarchy of ''requirements''. [[Business requirement]] is a business rationale for one or more changes that, when implemented, will permit the organization to increase revenue, avoid costs, improve service, or meet [[regulatory requirement]]s. The rationale commonly includes the organizational goals, objectives, and needs; it usually describes opportunities that an organization wants to realize or problems that they want to solve. A [[business case]] is the common form of a [[business requirement]].
 
:#'''[[Stakeholder requirement]]'''. Mid-level statements of the needs of a particular stakeholder or group of stakeholders. They usually describe how someone wants to interact with the intended solution. Often acting as a mid-point between the higher-level [[business requirement]]s and more detailed [[solution requirement]]s.  
 
:#'''[[Stakeholder requirement]]'''. Mid-level statements of the needs of a particular stakeholder or group of stakeholders. They usually describe how someone wants to interact with the intended solution. Often acting as a mid-point between the higher-level [[business requirement]]s and more detailed [[solution requirement]]s.  
−
:#[[Solution requirement]],  
+
:#'''[[Solution requirement]]''', including [[architecturally significant requirements]].
 
:#*[[Functional requirement]].
 
:#*[[Functional requirement]].
 
:#*[[Non-functional requirement]].
 
:#*[[Non-functional requirement]].
 
:#'''[[Transition requirement]]'''. The lowest level of the the [[International Institute of Business Analysis|IIBA]]'s hierarchy of ''requirements''. [[Transition requirement]]s are statements of capabilities or behavior required only to enable the transition from the current state of the enterprise to the desired future state, but that will thereafter no longer be required. Examples include recruitment, role changes, education, migration of data from one system to another.
 
:#'''[[Transition requirement]]'''. The lowest level of the the [[International Institute of Business Analysis|IIBA]]'s hierarchy of ''requirements''. [[Transition requirement]]s are statements of capabilities or behavior required only to enable the transition from the current state of the enterprise to the desired future state, but that will thereafter no longer be required. Examples include recruitment, role changes, education, migration of data from one system to another.
  
−
===INCOSE-developed taxonomy===
 
 
===FURPS+ system===
 
===FURPS+ system===
 +
:The [[FURPS|FURPS+]] system for requirements classification has been initially developed by Robert Grady at [[Hewlett-Packard]] and is now used widely in the [[industry]], most notably, by [[IBM]]. The acronym [[FURPS]] represents:
 +
:#[[Functionality]]
 +
:#[[Usability]]
 +
:#[[Reliability]]
 +
:#[[Performance]]
 +
:#[[Supportability]]
 +
 +
:The "+" in [[FURPS|FURPS+]] indicates concerns related to design requirements, implementation requirements, interface requirements, and/or physical requirements.
 +
 +
==Forms==
 +
===Artifacts===
 +
:Those artifacts that serve as ''requirements'' can be divided into two categories:
 +
:#'''[[Concept artifact]]s''' such as [[wireframe]]s, [[mockup]]s, [[prototype]]s, etc.
 +
:#'''Existing products''', especially competitor's ones.
 +
 +
===Initiating documents===
 +
:*[[Agreement]].
 +
:*[[Contract]].
 +
:*[[Business case]].
 +
:*[[Procurement statement of work]].
 +
:*[[Product epic]].
 +
:*[[Regulatory document]].
 +
:*[[Statement of work]] ([[Statement of work|SOW]]).
 +
 +
===Specifications===
 +
:''Main wikipage: [[Requirements specification]]''
 +
 +
:#'''[[Business requirements document]]''' ([[Business requirements document|BRD]]). Also known as a Business Needs Specification, a BRD is the first stage in a product life cycle. It details the problems that a product/service/system is trying to solve by logically listing high-level business requirements in relation to customers’ needs.
 +
:#'''[[Functional requirements document]]''' ([[Functional requirements document|FRD]]). An FRD defines in logical terms, how a system or project will accomplish the requirements laid out in the BRD. It outlines the functionality of the system in detail by capturing the intended behaviour of the system, expressed as services, tasks or functions that the developers have agreed to provide.
 +
:#'''[[Market requirements document]]''' ([[Market requirements document|MRD]]). Sometimes referred to as a Marketing Requirements Document, an MRD focuses on the target market’s needs. It typically explains: What the product is, who the target customers are, what products are in competition with it and why customers are likely to want this product.
 +
:#'''[[Product requirements document]]''' ([[Product requirements document|PRD]]). A PRD is used to communicate everything that must be included in a product release for it to be considered complete. It is written from a user’s point-of-view to understand what a product should do. It usually includes the same content as an FRD, but with ‘non-functional requirements’ added. Although non-functional requirements are not related to the functionality of the product, it’s often important to identify them - they may include such needs as reliability, security and scalability.
 +
:#'''[[Quality requirements document]]'''. The quality requirements document outlines the expectations of the customer for the quality of the final product. It consists of various criteria, factors and metrics that must be satisfied.
 +
:#'''[[Software requirements specification]]''' ([[Software requirements specification|SRS]]). An SRS outlines the features and the intended behaviour of a system. It describes the business’s understanding of the end user’s needs while laying out functional and nonfunctional requirements.
 +
:#'''[[Technical requirements document]]''' ([[Technical requirements document|TRD]]). A TRD contains the software, hardware and platform requirements of the product. It includes requirements like the programming language the system should be developed in and the processor speed required to run the system.
 +
:#'''[[User interface requirements document]]''' ([[User interface requirements document|UIRD]]). A UIRD describes the look and feel of the User Interface (UI) of the system.
 +
:#'''[[User requirements document]]''' ([[User requirements document|URD]]). A requirements document written for a user audience, describing user requirements and the impact of the anticipated changes on the users.
 +
 +
===Undocumented requests===
 +
 +
===Workteam documents===
 +
:To organize implementation of higher-level ''requirements'', [[workteam]]s casually use the following lower-level documents:
 +
:*In the '''[[Agile methodology]]''':
 +
:*#[[Product backlog]].
 +
:*#[[Sprint backlog]].
 +
:*#'''[[Epic story]]'''. A large [[user story]] that, in its current state, would be difficult to estimate or to complete in a single iteration. [[Epic story|Epic stori]]es are typically lower priority and are waiting be broken down into smaller components.
 +
:*#'''[[User story]]'''. A high-level, informal, brief, non-technical description of a solution capability that provides value to a stakeholder. In other words, a [[user story]] is description of a system requirement written from the [[customer]]'s or [[end-user]]'s point of view. A [[user story]] is typically one or two sentences long and provides the minimum information necessary to allow a developer to estimate the work required to implement it. Either the [[product owner]] or the team writes [[user story|user stori]]es according to the following structure: as a [type of user], I want to [perform some task (or execute some function)], so I can [achieve some goal].
 +
:*In the '''[[Waterfall model]]''':
 +
:*#[[Project task]].
 +
:*#[[Work order]].
 +
 +
==Process==
 +
===Analysis===
 +
:''Main wikipage: [[Business analysis]]''
 +
 +
:[[Business analysis]] is the set of [[enterprise effort]]s and [[technique]]s used to work as a liaison among stakeholders in order to understand the structure, policies and operations of an [[enterprise]], its [[business need]]s, and recommend solutions that enable the ''enterprise'' to achieve its goals. [[Use case]]s are examples of those solutions.
 +
 +
===Lifecycle===
 +
:''Main wikipage: [[Requirement lifecycle]]''
 +
 +
:A [[requirement lifecycle]] is the cycle through which ''requirements'' tend to go through from their [[requirements collection|collection]] to [[requirements implementation|implementation]].
  
 
===MoSCoW method===
 
===MoSCoW method===
 +
:The MoSCoW method (alternatively known as MoSCoW analysis, MoSCoW prioritization) is a prioritization technique used in [[business analysis]], [[enterprise administration]], [[project management]], and [[new product development]] to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement.
 +
 +
:The term, ''MoSCoW'', itself is an acronym derived from the first letter of each of four prioritization categories. Two interstitial ''O''s are added to make the word pronounceable:
 +
:#'''M'''ust have. The ''must-have requirements'' are critical to the current sprint; missing any of them constitutes a project failure.
 +
:#'''S'''hould have. The ''should-have requirements'' are important, but not necessary in the current sprint.
 +
:#'''C'''ould have. The ''could-have'' requirements are desirable but not necessary and can be included if time and other resources permit.
 +
:#'''W'''on't have at this time. The ''won't-have-this-time requirements'' are the least-critical, lowest-payback items, or not appropriate in the current sprint.
  
−
===Architectural===
+
===Responsible staffers===
−
:Architectural requirements explain what has to be done by identifying the necessary integration of systems [[structure]] and systems [[behavior]], i.e., [[systems architecture]] of a system.
+
:The customers' needs are the origin of the project, so the customer is ultimately responsible for determining their requirement. Governments are responsible for regulations. Other [[third party|third parti]]es impose expectations, standards, etc. Within the contractor organization, the following staffers are casually involved in developments of ''requirements'', usually the [[technical requirement|technical one]]s:
−
: In [[software engineering]], they are called [[Architecturally Significant Requirements|architecturally significant requirements]], which is defined as those requirements that have a measurable impact on a software system’s [[Software architecture|architecture]].
+
:#'''[[Business analyst]]'''.  is responsible for discovering the problem/requirements and determining the solution.
 +
:#'''[[Marketing manager]]'''. develops the marketing strategy for the project in line with its requirements.
 +
:#'''[[Product manager]]'''.  is responsible for defining the why, when, and what of the product that the development team will build.
 +
:#'''[[Product owner]]'''.
 +
:#'''[[Project manager]]'''.  is responsible for delivering the solution to a problem.
 +
:#'''[[Systems analyst]]'''. uses analysis and design to satisfy business requirements using information technology.
 +
:#'''[[Team lead]]'''.
  
−
===Quality-of-service (non-functional)===
+
==Evaluation criteria==
−
: Usually detailed statements of the conditions under which the solution must remain effective, qualities that the solution must have, or constraints within which it must operate. Examples include: reliability, testability, maintainability, availability.  They are also known as ''characteristics'', ''constraints'' or the ''[[ilities]].''
 
  
−
==Related concepts==
+
===Functional===
−
#[[Business need]]. A type of high-level [[business requirement]] that is a statement of a [[business objective]], or an impact the solution should have on its environment.
+
#Mobile client support
−
#'''[[Requirement]]'''. (1) A condition or capability needed by a stakeholder to solve a problem or achieve an objective; (2) A condition or capability that must be met of possessed by a [[deliverable]] or its component to satisfy a [[contract]], [[standard]], [[specification]], or other formally imposed documents; (3) A documented representation of a condition or capability as in 1) or 2).
+
#Content structuring:
−
#*[[Stated requirement]]. A requirement articulated by a stakeholder that has not been analyzed, verified, or validated. Stated requirements frequently reflect the desires of a stakeholder rather than the actual need.
+
#*Automatic updating of links to other pages when moved
−
#'''[[Business requirement]]'''. A higher level business rationale that, when addressed, will permit the organization to increase revenue, avoid costs, improve service, or meet regulatory requirements.
+
#*effort required to create a comprehensive structure
−
#*[[Stakeholder requirement]]. Stakeholder requirements are statements of the needs of a particular stakeholder or class of stakeholders. They describe the needs that a given stakeholder has and how that stakeholder will interact with a solution. Stakeholder requirements serve as a bridge between business requirements and the various categories of solution requirements.
+
#*classifying content into subject categories
−
#*[[Business requirements document]]. A [[requirements package]] that describes business requirements and stakeholder requirements (it documents requirements of interest to the business, rather than documenting business requirements).
+
#*HTML Tags
−
#[[File:Requirement.png|400px|thumb|right|[[Solution requirement]]]]'''[[Solution requirement]]'''. A characteristic of a solution that meets the business and stakeholder requirements. May be subdivided into functional and non-functional requirements.
+
#Ease of use
−
#*[[Functional requirement]]. Any [[requirement]] that refers to the [[product]] capabilities. In other words, a [[functional requirement]] describes what the product must do for its [[user]]s. In [[systems engineering]], a [[functional requirement]] is a particular behavior or [[metric]] to judge the operation of a [[system]].
+
#*Finding content
−
#*[[Non-functional requirement]](s). The quality attributes, design and implementation constraints, and external interfaces that the product must have.
+
#*Navigating up and down, back and forth
−
#*[[Technical requirement]]. A set of technical properties that a product must fulfill.
+
#*Commenting: Discussion Pages or Threaded?
−
#*[[Transition requirement]](s). A classification of requirements that describe capabilities that the solution must have in order to facilitate transition from the current state of the enterprise to the desired future state, but that will not be needed once that transition is complete.
+
#Ease of content creation
−
#'''[[Constraint]]'''. Any global [[requirement]] that limits the [[effort administration]] and/or [[effort result]]. The [[constraint]] is usually defined in order to restrict negative affects on [[business need]]s and those [[stakeholder applicable need|stakeholder need]]s that applicable to the particular [[project]] or [[operations]].
+
#*WYSIWYG editor
−
#*[[Design constraint]]. A [[solution requirement]] that limit the options available to the system designer.
+
#*Quoting
−
#*[[Technical constraint]](s). Technical constraints are limitations on the design of a solution that derive from the technology used in its implementation. See also business constraint.
+
#*Image Editing
−
#*[[Business constraint]](s). Business constraints are limitations placed on the solution design by the organization that needs the solution. Business constraints describe limitations on available solutions, or an aspect of the current state that cannot be changed by the deployment of the new solution. See also technical constraint.
+
#*SVG Editing
−
#'''[[Requirements model]]'''. A representation of requirements using text and diagrams. Requirements models can also be called user requirements models or analysis models and can supplement textual requirements specifications.
+
#Ease of collaborative participation
−
#*[[Requirement attribute]]. Metadata related to a requirement used to assist with requirements development and management.
+
#*Concurrent editing
−
#*[[Requirement defect]]. An error in requirements caused by incorrect, incomplete, missing, or conflicting requirements.
+
#Content Management – Version tracking
−
#*[[Requirements allocation]]. The process of apportioning requirements to subsystems and components (i.e., people, hardware, and software).
+
#Modularity of installed components – Do they all have to be installed? If not, can they be installed at anytime?
−
#*[[Requirements traceability]]. The ability to identify and document the lineage of each requirement, including its derivation (backward traceability), its allocation (forward traceability), and its relationship to other requirements.
+
#Additional functionality
−
#'''[[User requirements document]]'''. A requirements document written for a user audience, describing user requirements and the impact of the anticipated changes on the users.
+
#*Full text search
−
#*[[Requirements package]]. A requirements package is a set of requirements grouped together in a document or presentation for communication to stakeholders.
+
#*Blogs/Forums
−
#*[[Specification]]. The exact customer needs that must be satisfied by a product in order for that product to be considered a success.
+
#*Email Notification
−
#'''[[User story]]'''. A high-level, informal, brief, non-technical description of a solution capability that provides value to a stakeholder. In other words, a [[user story]] is description of a system requirement written from the [[customer]]'s or [[end-user]]'s point of view. A [[user story]] is typically one or two sentences long and provides the minimum information necessary to allow a developer to estimate the work required to implement it. Either the [[product owner]] or the team writes [[user story|user stori]]es according to the following structure: as a [type of user], I want to [perform some task (or execute some function)], so I can [achieve some goal].
+
#*Calendar
−
#*[[Product epic]]. A large user story that, in its current state, would be difficult to estimate or to complete in a single iteration. [[Epic story|Epic stori]]es are typically lower priority and are waiting be broken down into smaller components.
+
#*Structured data
−
#*[[Story mapping]]. refers to a top-down visualization, or roadmap, of product backlog. The story map starts with a goal or specific functionality, which is then broken down into user stories. A story map is created in tree format either physically, using post-its on a wall, or digitally.
+
#*Structured data trackers, analysis and report tools
−
#*[[Story point]]. A measurement used by [[Scrum team]]s to determine how much [[effort]] is required to achieve a goal. In other words, a [[story point]] is a non-unit measure used to determine the complexity of a [[user story]]. [[Story point]]s are relative, not absolute, and do not relate to actual hours. They can be anything from [[Agile T-shirt size]]s to the [[Fibonacci sequence]].
+
#*RSS Syndication
−
#*[[Storyboard]]. A tool inspired by the filmmaking industry, where a visual sequence of events is used to capture a user's interactions with a product. Depending on the audience, it may be an extremely rough sketch, purely for crystallising your own ideas.
+
#*File Galleries
−
#*[[User persona]]. (1) A fictitious identity that reflects one of the user groups for whom the product is being designed; (2) A detailed hypothetical description or biography of a typical [[end-user]] who will be using the product. [[User persona]]s usually take the form of a written document, complete with stock photo, name, profession, style of living, and other details pertinent to their being categorized as an [[end-user]].
+
#*Articles
−
#*[[Spike]]. A short, time-boxed piece of research, usually technical, on a single story that is intended to provide just enough information that the team can estimate the size of the [[user story]].
+
#*FAQs
−
#'''[[Use case]]'''. An analysis model that describes the tasks that the system will perform for actors and the goals that the system achieves for those actors along the way.
+
#*Quizzes
−
#*[[Included use case]]. A use case composed of a common set of steps used by multiple use cases.
+
#*Featured links
−
#*[[Use case diagram]]. A type of diagram defined by UML that captures all actors and use cases involved with a system or product.
+
#*Slideshow
−
#*[[Work product]]. A document or collection of notes or diagrams used by the [[business analyst]] during the requirements development process.
+
#*Messages
−
#'''[[Verified requirement]]'''. Requirements that have been shown to demonstrate the characteristics of requirements quality and as such are cohesive, complete, consistent, correct, feasible, modifiable, unambiguous, and testable.
+
#*Chat
−
#*[[Requirements verification]]. The work done to evaluate requirements to ensure they are defined correctly and are at an acceptable level of quality. It ensures the requirements are sufficiently defined and structured so that the solution development team can use them in the design, development and implementation of the solution.
+
#*Newsletters
−
#'''[[Validated requirement]]'''. A requirement that has been demonstrated to deliver business value and to support the business goals and objectives.
+
#*Shoutbox
−
#*[[Requirements validation]]. The work done to ensure that the stated requirements support and are aligned with the goals and objectives of the business.
+
#Dynamic Content
 +
#Automatic Table of Contents
 +
#Create links easily with other wikis
 +
#Content Template
 +
 
 +
===Non-functional===
 +
#Security
 +
#*LDAP use built in or through plug-in
 +
#*Back-end Authentication Methods Supported, e.g., OpenID, Active Directory, LDAP, Shibboleth, CAS, IMAP
 +
#*ACL Support
 +
#*User and Group Management granularity
 +
#*Email encryption
 +
#Wiki Release schedule
 +
#Size of development community
 +
#Extensible programming language
 +
#Plug-in availability
 +
#*Internal
 +
#*External
 +
#Import
 +
#*From Media-wiki
 +
#*From other sources
 +
#Export to various formats
 +
#Data store
 +
#Programming languages supported
 +
#Support
 +
#*Forums
 +
#*Mailing lists
 +
#*Chat Channel
  
−
==Related lectures==
 
−
*[[Business Analysis Quarter]].
 
 
==See also==
 
==See also==
 
*https://www.iiba.org/certification/iiba-certifications/#core
 
*https://www.iiba.org/certification/iiba-certifications/#core
−
*https://businessanalysisexperts.com/Job_Aids_RSG/RequirementsTaxonomy.pdf
 
 
*https://www.intechopen.com/books/interdisciplinary-approaches-to-semiotics/grounding-functional-requirements-classification-in-organizational-semiotics
 
*https://www.intechopen.com/books/interdisciplinary-approaches-to-semiotics/grounding-functional-requirements-classification-in-organizational-semiotics
 
*https://www.cse.msu.edu/~cse870/IEEEXplore-SRS-template.pdf
 
*https://www.cse.msu.edu/~cse870/IEEEXplore-SRS-template.pdf
 
*https://en.wikipedia.org/wiki/Software_requirements_specification
 
*https://en.wikipedia.org/wiki/Software_requirements_specification
−
*http://www.pages.drexel.edu/~sga72/docs/SRSwithUseCases.pdf
 
 
*https://www.ibm.com/developerworks/rational/library/4706.html
 
*https://www.ibm.com/developerworks/rational/library/4706.html
 +
*https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/5464/9-Types-Of-Requirements-Documents-What-They-Mean-And-Who-Writes-Them.aspx
 
*https://dzone.com/articles/remote-agile-part-1-practices-amp-tools
 
*https://dzone.com/articles/remote-agile-part-1-practices-amp-tools
 
*https://dzone.com/articles/what-are-the-project-management-tools-that-are-use
 
*https://dzone.com/articles/what-are-the-project-management-tools-that-are-use
  
−
[[Category: Septem Artes Administrativi]][[Category: Articles]]
+
===Related lectures===
 +
:*[[Business Analysis Quarter]].
 +
:*[[What Requirements Are]].
 +
 
 +
[[Category: Septem Artes Administrativi]][[Category: CNM Cyber Orientation]][[Category: Articles]][[Category: Business Analysis]][[Category: Systems Engineering]]

Latest revision as of 13:35, 6 May 2023

A requirement is an expressed demand, desire, expectation, and/or wish to have or not to have a certain market exchangeable and/or a certain capability, condition, feature, and/or property. The plural term, requirements, may refer to the aggregate of various requirements that the product owner or another authority for the requested product and/or its development process has approved, verified, and/or validated. Those requirements that limit the market exchangeable's or process of the production's capabilities and/or conditions are called constraints.


Definitions

According to the INCOSE Systems Engineering Handbook (4th edition),

Requirement. A statement that identifies a system, product, or process characteristic or constraint, which is unambiguous, clear, unique, consistent, stand‐alone (not grouped), and verifiable, and is deemed necessary for stakeholder acceptability.

Common definitions

The common-style definitions particularly include:

Engineering definitions

According to the Rational Unified Process (RUP), which is an iterative software development process framework that IBM markets,
A requirement describes a condition or capability to which a system must conform; either derived directly from user needs, or stated in a contract, standard, specification, or other formally imposed document.
According to the second version of the A Guide to the Business Analysis Body of Knowledge® (BABOK Guide), a requirement is:
  1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective;
  2. A condition or capability that must be met of possessed by a deliverable or its component to satisfy a contract, standard, specification, or other formally imposed documents; AND/OR
  3. A documented representation of a condition or capability as in (1) or (2).
The IEEE Standard Glossary of Software Engineering Terminology defines a requirement similarly to the two definitions above.

According to the BABOK Guide (3rd edition),

Requirement. A usable representation of a need.

Stakeholder definitions

From a stakeholder perspective, a requirement is anything that helps:
  1. Customers to describe what they wish to obtain;
  2. Suppliers to understand what the customer wants;
  3. Requirements staffers to substantively develop requirements blueprints for their own organizations, as well as other requirements documents such as requirements quality checklists, requirements creator's handbooks, etc.

Applications

Requirements are widely used in business analysis, process optimization, procurement, product development, project management, systems engineering, and many other areas. Because of variety of applications, several views of what requirements are, how they should be organized and how they should be utilized compete against each other.

Business analysis

Requirements for the solutions to be designed, developed, and delivered are in the core of business analysis.

New product development

Requirements for the market exchangeables to be designed, developed, and delivered are in the core of new product development. Hewlett-Packard developed the FURPS system, which is quite popular in the software development and particularly promoted by IBM. The Agile methodologies widely use product requirements in forms of user story, epic story, and so on.

Procurement

Requirements for the market exchangeables to be purchased are in the core of procurement. Forms of the procurement requirements range from oral statements such as I would like to buy the cheapest soap you carry and up to procurement statements of work, business cases, etc.

Project management

Requirements for the unique product, service, or result to be designed, created, and delivered are in the core of project management. AXELOS Ltd and the PMI lead the industry research on requirements.

Sales engineering

Requirements for the products to be sold are in the core of sales engineering. Regardless of the fact whether anyone in marketing and sales knows what the term, requirement, means, any good sales representative asks a potential buyer about what he or she wants to buy at least and, probably, on what conditions and at what price.

Systems engineering

Requirements for the systems to be designed, developed, and delivered are in the core of systems engineering. The IEEE and the INCOSE lead the industry research on requirements.

Natural classifications

Categorized by audiences

Requirements developers develop requirements. There two major pairs of audiences that primarily consume those requirements:
  1. Customer and contractor when the requirements are needed to understand or confirm what needs to be done and, possibly, how what needs to be done would be done.
  2. Contractor's management and implementing staffers when a set of requirements needs to be bettered and/or broken-down in order to be implemented by a contractor's team and/or subcontractors. This type of requirements is often called technical requirements.

Categorized by imposing party

Any requirement can be imposed by one or more of the following three:
  1. Customer, who states what is needed to be solved and, possibly, how what needs to be solved should be solved;
  2. Contractor, who has its own circumstances, both resources and limitations;
  3. Third party such as:
Some requirements are originated from the sources such as demographics, economy, and geography that are outside of those three, but they need to be brought to the operations or project by one of those three.

Categorized by progress

Requirements can be categorized based on their state in the requirement lifecycle:
  1. Stated requirement. A requirement articulated by a stakeholder that has not been analyzed, verified, or validated. Stated requirements frequently reflect the desires of a stakeholder rather than the actual need.
  2. Confirmed requirement.
  3. Prioritized requirement.
  4. Organized requirement.
  5. Modeled requirement.
  6. Verified requirement. Requirements that have been shown to demonstrate the characteristics of requirements quality and as such are cohesive, complete, consistent, correct, feasible, modifiable, unambiguous, and testable.
  7. Validated requirement. A requirement that has been demonstrated to deliver business value and to support the business goals and objectives.
  8. Reviewed requirement.
  9. Approved requirement.
  10. Implemented requirement.

Product vs process

With regard to its nature, a requirement may refer to:

Modeled classifications

Because of the variety of research frameworks, a few competitive taxonomies exist.

IIBA-marketed taxonomy

Particularly through their BABOK Guide, the IIBA markets the following taxonomy:
  1. Business requirement. The highest level of the the IIBA's hierarchy of requirements. Business requirement is a business rationale for one or more changes that, when implemented, will permit the organization to increase revenue, avoid costs, improve service, or meet regulatory requirements. The rationale commonly includes the organizational goals, objectives, and needs; it usually describes opportunities that an organization wants to realize or problems that they want to solve. A business case is the common form of a business requirement.
  2. Stakeholder requirement. Mid-level statements of the needs of a particular stakeholder or group of stakeholders. They usually describe how someone wants to interact with the intended solution. Often acting as a mid-point between the higher-level business requirements and more detailed solution requirements.
  3. Solution requirement, including architecturally significant requirements.
  4. Transition requirement. The lowest level of the the IIBA's hierarchy of requirements. Transition requirements are statements of capabilities or behavior required only to enable the transition from the current state of the enterprise to the desired future state, but that will thereafter no longer be required. Examples include recruitment, role changes, education, migration of data from one system to another.

FURPS+ system

The FURPS+ system for requirements classification has been initially developed by Robert Grady at Hewlett-Packard and is now used widely in the industry, most notably, by IBM. The acronym FURPS represents:
  1. Functionality
  2. Usability
  3. Reliability
  4. Performance
  5. Supportability
The "+" in FURPS+ indicates concerns related to design requirements, implementation requirements, interface requirements, and/or physical requirements.

Forms

Artifacts

Those artifacts that serve as requirements can be divided into two categories:
  1. Concept artifacts such as wireframes, mockups, prototypes, etc.
  2. Existing products, especially competitor's ones.

Initiating documents

Specifications

Main wikipage: Requirements specification
  1. Business requirements document (BRD). Also known as a Business Needs Specification, a BRD is the first stage in a product life cycle. It details the problems that a product/service/system is trying to solve by logically listing high-level business requirements in relation to customers’ needs.
  2. Functional requirements document (FRD). An FRD defines in logical terms, how a system or project will accomplish the requirements laid out in the BRD. It outlines the functionality of the system in detail by capturing the intended behaviour of the system, expressed as services, tasks or functions that the developers have agreed to provide.
  3. Market requirements document (MRD). Sometimes referred to as a Marketing Requirements Document, an MRD focuses on the target market’s needs. It typically explains: What the product is, who the target customers are, what products are in competition with it and why customers are likely to want this product.
  4. Product requirements document (PRD). A PRD is used to communicate everything that must be included in a product release for it to be considered complete. It is written from a user’s point-of-view to understand what a product should do. It usually includes the same content as an FRD, but with ‘non-functional requirements’ added. Although non-functional requirements are not related to the functionality of the product, it’s often important to identify them - they may include such needs as reliability, security and scalability.
  5. Quality requirements document. The quality requirements document outlines the expectations of the customer for the quality of the final product. It consists of various criteria, factors and metrics that must be satisfied.
  6. Software requirements specification (SRS). An SRS outlines the features and the intended behaviour of a system. It describes the business’s understanding of the end user’s needs while laying out functional and nonfunctional requirements.
  7. Technical requirements document (TRD). A TRD contains the software, hardware and platform requirements of the product. It includes requirements like the programming language the system should be developed in and the processor speed required to run the system.
  8. User interface requirements document (UIRD). A UIRD describes the look and feel of the User Interface (UI) of the system.
  9. User requirements document (URD). A requirements document written for a user audience, describing user requirements and the impact of the anticipated changes on the users.

Undocumented requests

Workteam documents

To organize implementation of higher-level requirements, workteams casually use the following lower-level documents:
  • In the Agile methodology:
    1. Product backlog.
    2. Sprint backlog.
    3. Epic story. A large user story that, in its current state, would be difficult to estimate or to complete in a single iteration. Epic stories are typically lower priority and are waiting be broken down into smaller components.
    4. User story. A high-level, informal, brief, non-technical description of a solution capability that provides value to a stakeholder. In other words, a user story is description of a system requirement written from the customer's or end-user's point of view. A user story is typically one or two sentences long and provides the minimum information necessary to allow a developer to estimate the work required to implement it. Either the product owner or the team writes user stories according to the following structure: as a [type of user], I want to [perform some task (or execute some function)], so I can [achieve some goal].
  • In the Waterfall model:
    1. Project task.
    2. Work order.

Process

Analysis

Main wikipage: Business analysis
Business analysis is the set of enterprise efforts and techniques used to work as a liaison among stakeholders in order to understand the structure, policies and operations of an enterprise, its business needs, and recommend solutions that enable the enterprise to achieve its goals. Use cases are examples of those solutions.

Lifecycle

Main wikipage: Requirement lifecycle
A requirement lifecycle is the cycle through which requirements tend to go through from their collection to implementation.

MoSCoW method

The MoSCoW method (alternatively known as MoSCoW analysis, MoSCoW prioritization) is a prioritization technique used in business analysis, enterprise administration, project management, and new product development to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement.
The term, MoSCoW, itself is an acronym derived from the first letter of each of four prioritization categories. Two interstitial Os are added to make the word pronounceable:
  1. Must have. The must-have requirements are critical to the current sprint; missing any of them constitutes a project failure.
  2. Should have. The should-have requirements are important, but not necessary in the current sprint.
  3. Could have. The could-have requirements are desirable but not necessary and can be included if time and other resources permit.
  4. Won't have at this time. The won't-have-this-time requirements are the least-critical, lowest-payback items, or not appropriate in the current sprint.

Responsible staffers

The customers' needs are the origin of the project, so the customer is ultimately responsible for determining their requirement. Governments are responsible for regulations. Other third parties impose expectations, standards, etc. Within the contractor organization, the following staffers are casually involved in developments of requirements, usually the technical ones:
  1. Business analyst. is responsible for discovering the problem/requirements and determining the solution.
  2. Marketing manager. develops the marketing strategy for the project in line with its requirements.
  3. Product manager. is responsible for defining the why, when, and what of the product that the development team will build.
  4. Product owner.
  5. Project manager. is responsible for delivering the solution to a problem.
  6. Systems analyst. uses analysis and design to satisfy business requirements using information technology.
  7. Team lead.

Evaluation criteria

Functional

  1. Mobile client support
  2. Content structuring:
    • Automatic updating of links to other pages when moved
    • effort required to create a comprehensive structure
    • classifying content into subject categories
    • HTML Tags
  3. Ease of use
    • Finding content
    • Navigating up and down, back and forth
    • Commenting: Discussion Pages or Threaded?
  4. Ease of content creation
    • WYSIWYG editor
    • Quoting
    • Image Editing
    • SVG Editing
  5. Ease of collaborative participation
    • Concurrent editing
  6. Content Management – Version tracking
  7. Modularity of installed components – Do they all have to be installed? If not, can they be installed at anytime?
  8. Additional functionality
    • Full text search
    • Blogs/Forums
    • Email Notification
    • Calendar
    • Structured data
    • Structured data trackers, analysis and report tools
    • RSS Syndication
    • File Galleries
    • Articles
    • FAQs
    • Quizzes
    • Featured links
    • Slideshow
    • Messages
    • Chat
    • Newsletters
    • Shoutbox
  9. Dynamic Content
  10. Automatic Table of Contents
  11. Create links easily with other wikis
  12. Content Template

Non-functional

  1. Security
    • LDAP use built in or through plug-in
    • Back-end Authentication Methods Supported, e.g., OpenID, Active Directory, LDAP, Shibboleth, CAS, IMAP
    • ACL Support
    • User and Group Management granularity
    • Email encryption
  2. Wiki Release schedule
  3. Size of development community
  4. Extensible programming language
  5. Plug-in availability
    • Internal
    • External
  6. Import
    • From Media-wiki
    • From other sources
  7. Export to various formats
  8. Data store
  9. Programming languages supported
  10. Support
    • Forums
    • Mailing lists
    • Chat Channel

See also

Related lectures

Retrieved from "https://pravka.bskol.com/w/index.php?title=Requirement&oldid=100066"