HOME

TheInfoList




In
systems engineering Systems engineering is an interdisciplinary Interdisciplinarity or interdisciplinary studies involves the combination of two or more academic disciplines into one activity (e.g., a research project). It draws knowledge from several other f ...
and
software engineering Software engineering is the systematic application of engineering Engineering is the use of scientific principles to design and build machines, structures, and other items, including bridges, tunnels, roads, vehicles, and buildings. The d ...
, requirements analysis focuses on the tasks that determine the needs or conditions to meet the new or altered product or project, taking account of the possibly conflicting
requirement In product development In business Business is the activity of making one's living or making money by producing or buying and selling products (such as goods and services). Simply put, it is "any activity or enterprise entered into for p ...
s of the various
stakeholders Stakeholder may refer to: *Stakeholder (corporate), a group, corporate, organization, member, or system that affects or can be affected by an organization's actions *Project stakeholder, a person, group, or organization with an interest in a projec ...
, ''analyzing, documenting, validating and managing'' software or system requirements. Requirements analysis is critical to the success or failure of a systems or
software project Software project management is an art and science of planning and leading software projects. It is a sub-discipline of project management Project management is the process of leading the work of a team A team is a group of individuals (hum ...
. The requirements should be documented, actionable, measurable, testable, traceable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.


Overview

Conceptually, requirements analysis includes three types of activities: * Eliciting requirements: (e.g. the project charter or definition), business process documentation, and stakeholder interviews. This is sometimes also called requirements gathering or requirements discovery. *Recording requirements: Requirements may be documented in various forms, usually including a summary list and may include natural-language documents,
use case In software engineering, software and systems engineering, the phrase use case is a Polysemy, polyseme with two Word sense, senses: # A usage scenario for a piece of software; often used in the plural to suggest situations where a piece of soft ...

use case
s,
user stories In software development and product management, a user story is an informal, natural language description of features of a software system. They are written from the perspective of an User (computing)#End-user, end user or User (system), user of a ...
, process specifications and a variety of models including data models. *Analyzing requirements: determining whether the stated requirements are clear, complete, unduplicated, concise, valid, consistent and unambiguous, and resolving any apparent conflicts. Analyzing can also include sizing requirements. Requirements analysis can be a long and tiring process during which many delicate psychological skills are involved. New systems change the environment and relationships between people, so it is important to identify all the stakeholders, take into account all their needs and ensure they understand the implications of the new systems. Analysts can employ several techniques to elicit the requirements from the customer. These may include the development of scenarios (represented as
user stories In software development and product management, a user story is an informal, natural language description of features of a software system. They are written from the perspective of an User (computing)#End-user, end user or User (system), user of a ...
in agile methods), the identification of
use case In software engineering, software and systems engineering, the phrase use case is a Polysemy, polyseme with two Word sense, senses: # A usage scenario for a piece of software; often used in the plural to suggest situations where a piece of soft ...

use case
s, the use of workplace observation or
ethnography Ethnography (from Greek#REDIRECT Greek Greek may refer to: Greece Anything of, from, or related to Greece Greece ( el, Ελλάδα, , ), officially the Hellenic Republic, is a country located in Southeast Europe. Its population is ap ...

ethnography
, holding
interview An interview is essentially a structured conversation Conversation is interactive communication Communication (from Latin ''communicare'', meaning "to share" or "to be in relation with") is "an apparent answer to the painful divi ...

interview
s, or
focus group A focus group is a group interview involving a small number of demographically similar people or participants who have other common traits/experiences. Their reactions to specific researcher/evaluator-posed questions are studied. Focus groups are ...
s (more aptly named in this context as requirements workshops, or requirements review sessions) and creating requirements lists.
Prototyping A prototype is an early sample, model, or release of a product built to test a concept or process. It is a term used in a variety of contexts, including semantics Semantics (from grc, σημαντικός ''sēmantikós'', "significant" ...

Prototyping
may be used to develop an example system that can be demonstrated to stakeholders. Where necessary, the analyst will employ a combination of these methods to establish the exact requirements of the stakeholders, so that a system that meets the business needs is produced. Requirements quality can be improved through these and other methods * Visualization. Using tools that promote better understanding of the desired end-product such as visualization and simulation. * Consistent use of templates. Producing a consistent set of models and templates to document the requirements. * Documenting dependencies. Documenting dependencies and interrelationships among requirements, as well as any assumptions and congregations.


Requirements analysis topics


Stakeholder identification

See
Stakeholder analysis Stakeholder analysis (in conflict resolution, business administration, environmental health sciences decision making, Industrial ecology, and project management) is the process of assessing a system and potential changes to it as they relate to rele ...
for a discussion of people or organizations (legal entities such as companies, standards bodies) that have a valid interest in the system. They may be affected by it either directly or indirectly. A major new emphasis in the 1990s was a focus on the identification of ''stakeholders''. It is increasingly recognized that stakeholders are not limited to the organization employing the analyst. Other stakeholders will include: * anyone who operates the system (normal and maintenance operators) * anyone who benefits from the system (functional, political, financial and social beneficiaries) * anyone involved in purchasing or procuring the system. In a mass-market product organization, product management, marketing and sometimes sales act as surrogate consumers (mass-market customers) to guide development of the product. * organizations which regulate aspects of the system (financial, safety, and other regulators) * people or organizations opposed to the system (negative stakeholders; see also Misuse case) * organizations responsible for systems which interface with the system under design. * those organizations who integrate horizontally with the organization for whom the analyst is designing the system.


Joint Requirements Development (JRD) Sessions

Requirements often have cross-functional implications that are unknown to individual stakeholders and often missed or incompletely defined during stakeholder interviews. These cross-functional implications can be elicited by conducting JRD sessions in a controlled environment, facilitated by a trained
facilitator A facilitator is a person who helps a Social group, group of people to work together better, understand their common objectives, and plan how to achieve these objectives, during meetings or discussions. In doing so, the facilitator remains "neutr ...

facilitator
(Business Analyst), wherein stakeholders participate in discussions to elicit requirements, analyze their details and uncover cross-functional implications. A dedicated scribe should be present to document the discussion, freeing up the Business Analyst to lead the discussion in a direction that generates appropriate requirements which meet the session objective. JRD Sessions are analogous to
Joint Application Design Joint application design (JAD) is a process used in the life cycle area of the dynamic systems development method Dynamic systems development method (DSDM) is an Agile management, agile project delivery framework, initially used as a software d ...
Sessions. In the former, the sessions elicit requirements that guide design, whereas the latter elicit the specific design features to be implemented in satisfaction of elicited requirements.


Contract-style requirement lists

One traditional way of documenting requirements has been contract style requirement lists. In a complex system such requirements lists can run to hundreds of pages long. An appropriate metaphor would be an extremely long shopping list. Such lists are very much out of favour in modern analysis; as they have proved spectacularly unsuccessful at achieving their aims; but they are still seen to this day.


Strengths

* Provides a checklist of requirements. * Provide a contract between the project sponsor(s) and developers. * For a large system can provide a high level description from which lower-level requirements can be derived.


Weaknesses

* Such lists can run to hundreds of pages. They are not intended to serve as a reader-friendly description of the desired application. * Such requirements lists abstract all the requirements and so there is little context. The Business Analyst may include context for requirements in accompanying design documentation. ** This abstraction is not intended to describe how the requirements fit or work together. ** The list may not reflect relationships and dependencies between requirements. While a list does make it easy to prioritize each individual item, removing one item out of context can render an entire use case or business requirement useless. ** The list doesn't supplant the need to review requirements carefully with stakeholders in order to gain a better shared understanding of the implications for the design of the desired system / application. * Simply creating a list does not guarantee its completeness. The Business Analyst must make a good faith effort to discover and collect a substantially comprehensive list, and rely on stakeholders to point out missing requirements. * These lists can create a false sense of mutual understanding between the stakeholders and developers; Business Analysts are critical to the translation process. * It is almost impossible to uncover all the functional requirements before the process of development and testing begins. If these lists are treated as an immutable contract, then requirements that emerge in the Development process may generate a controversial change request.


Alternative to requirement lists

As an alternative to requirement lists,
Agile Software Development In software development Software development is the process of conceiving, specifying, designing, programming, documenting, testing, and bug fixing involved in creating and maintaining applications Application may refer to: Mathematics a ...
uses
User stories In software development and product management, a user story is an informal, natural language description of features of a software system. They are written from the perspective of an User (computing)#End-user, end user or User (system), user of a ...
to suggest requirements in everyday language.


Measurable goals

Best practices take the composed list of requirements merely as clues and repeatedly ask "why?" until the actual business purposes are discovered. Stakeholders and developers can then devise tests to measure what level of each goal has been achieved thus far. Such goals change more slowly than the long list of specific but unmeasured requirements. Once a small set of critical, measured goals has been established,
rapid prototyping Rapid prototyping is a group of techniques used to quickly fabricate a scale model Scale or scales may refer to: Mathematics * Scale (descriptive set theory) In the mathematical discipline of descriptive set theory, a scale is a certain kind ...
and short iterative development phases may proceed to deliver actual stakeholder value long before the project is half over.


Prototypes

A prototype is a computer program that exhibits a part of the properties of another computer program, allowing users to visualize an application that has not yet been constructed. A popular form of prototype is a
mockup In manufacturing Manufacturing is the creation or Production (economics), production of goods with the help of equipment, Work (human activity), labor, machines, tools, and chemical or biological processing or formulation. It is the essenc ...
, which helps future users and other stakeholders to get an idea of what the system will look like. Prototypes make it easier to make design decisions, because aspects of the application can be seen and shared before the application is built. Major improvements in communication between users and developers were often seen with the introduction of prototypes. Early views of applications led to fewer changes later and hence reduced overall costs considerably. Prototypes can be flat diagrams (often referred to as wireframes) or working applications using synthesized functionality. Wireframes are made in a variety of graphic design documents, and often remove all color from the design (i.e. use a greyscale color palette) in instances where the final software is expected to have
graphic design Graphic design is the profession A Profession is a disciplined group of individuals who adhere to ethical standards and who hold themselves out as, and are accepted by the public as possessing special knowledge and skills in a widely recogni ...
applied to it. This helps to prevent confusion as to whether the prototype represents the final visual look and feel of the application.


Use cases

A use case is a structure for documenting the functional requirements for a system, usually involving software, whether that is new or being changed. Each use case provides a set of ''scenarios'' that convey how the system should interact with a human user or another system, to achieve a specific business goal. Use cases typically avoid technical jargon, preferring instead the language of the
end-user In product development, an end user (sometimes end-user) is a person who ultimately uses or is intended to ultimately use a product. The end user stands in contrast to users who support or maintain the product, such as sysop A sysop (; an abbre ...
or ''
domain expert A subject-matter expert (SME) is a person who is an authority in a particular area or topic. The term is used when developing materials about a topic (a book, an examination, a manual, etc.), and expertise on the topic is needed by the personnel ...
''. Use cases are often co-authored by requirements engineers and stakeholders. Use cases are deceptively simple tools for describing the behavior of software or systems. A use case contains a textual description of the ways in which users are intended to work with the software or system. Use cases should not describe internal workings of the system, nor should they explain how that system will be implemented. Instead, they show the steps needed to perform a task without sequential assumptions.


Requirements specification

Requirements specification is the synthesis of discovery findings regarding current state business needs and the assessment of these needs to determine, and specify, what is required to meet the needs within the solution scope in focus. Discovery, analysis and specification move the understanding from a current as-is state to a future to-be state. Requirements specification can cover the full breadth and depth of the future state to be realized, or it could target specific gaps to fill, such as priority software system bugs to fix and enhancements to make. Given that any large business process almost always employs software and data systems and technology, requirements specification is often associated with software system builds, purchases, cloud computing strategies, embedded software in products or devices, or other technologies. The broader definition of requirements specification includes or focuses on any solution strategy or component, such as training, documentation guides, personnel, marketing strategies, equipment, supplies, etc.


Types of requirements

Requirement In product development In business Business is the activity of making one's living or making money by producing or buying and selling products (such as goods and services). Simply put, it is "any activity or enterprise entered into for p ...
s are
categorized
categorized
in several ways. The following are common categorizations of requirements that relate to technical management: ;Business requirements : Statements of business level goals, without reference to detailed functionality. These are usually high level (software and/or hardware) capabilities that are needed to achieve a business outcome. ;Customer requirements : Statements of fact and assumptions that define the expectations of the system in terms of mission objectives, environment, constraints, and measures of effectiveness and suitability (MOE/MOS). The customers are those that perform the eight primary functions of systems engineering, with special emphasis on the operator as the key customer. Operational requirements will define the basic need and, at a minimum, answer the questions posed in the following listing: :*''Operational distribution or deployment'': Where will the system be used? :*''Mission profile or scenario'': How will the system accomplish its mission objective? :*''Performance and related parameters'': What are the critical system parameters to accomplish the mission? :*''Utilization environments'': How are the various system components to be used? :*''Effectiveness requirements'': How effective or efficient must the system be in performing its mission? :*''Operational life cycle'': How long will the system be in use by the user? :*''Environment'': What environments will the system be expected to operate in an effective manner? ;Architectural requirements: Architectural requirements explain what has to be done by identifying the necessary
systems architecture A system architecture is the conceptual model A conceptual model is a representation Representation may refer to: Law and politics *Representation (politics) Political representation is the activity of making citizens "present" in public policy ...
of a
system A system is a group of Interaction, interacting or interrelated elements that act according to a set of rules to form a unified whole. A system, surrounded and influenced by its environment, is described by its boundaries, structure and purp ...

system
. ;Structural requirements: Structural requirements explain what has to be done by identifying the necessary
structure A structure is an arrangement and organization of interrelated elements in a material object or system A system is a group of Interaction, interacting or interrelated elements that act according to a set of rules to form a unified whole. ...

structure
of a system. ;Behavioral requirements: Behavioral requirements explain what has to be done by identifying the necessary
behavior Behavior (American English American English (AmE, AE, AmEng, USEng, en-US), sometimes called United States English or U.S. English, is the set of variety (linguistics), varieties of the English language native to the United States. Cur ...
of a system. ;Functional requirements:
Functional requirement In software engineering Software engineering is the systematic application of engineering Engineering is the use of scientific principles to design and build machines, structures, and other items, including bridges, tunnels, roads, vehicl ...
s explain what has to be done by identifying the necessary task, action or activity that must be accomplished. Functional requirements analysis will be used as the toplevel functions for functional analysis. ;Non-functional requirements:
Non-functional requirement In systems engineering Systems engineering is an field of and that focuses on how to design, integrate, and manage s over their s. At its core, systems engineering utilizes principles to organize this body of knowledge. The individual outc ...
s are requirements that specify criteria that can be used to judge the operation of a system, rather than specific behaviors. ;Performance requirements: The extent to which a mission or function must be executed; generally measured in terms of quantity, quality, coverage, timeliness or readiness. During requirements analysis, performance (how well does it have to be done) requirements will be interactively developed across all identified functions based on system life cycle factors; and characterized in terms of the degree of certainty in their estimate, the degree of criticality to system success, and their relationship to other requirements. ;Design requirements: The "build to", "code to", and "buy to" requirements for products and "how to execute" requirements for processes expressed in technical data packages and technical manuals. ;Derived requirements: Requirements that are implied or transformed from higher-level requirement. For example, a requirement for long range or high speed may result in a design requirement for low weight. ;Allocated requirements: A requirement that is established by dividing or otherwise allocating a high-level requirement into multiple lower-level requirements. Example: A 100-pound item that consists of two subsystems might result in weight requirements of 70 pounds and 30 pounds for the two lower-level items. Well-known requirements categorization models include
FURPS FURPS is an acronym representing a model for classifying software quality attributes (Functional requirements, functional and Non-functional requirements, non-functional requirements): * Functional requirement, Functionality - Capability (Size & G ...
and FURPS+, developed at
Hewlett-Packard The Hewlett-Packard Company, commonly shortened to Hewlett-Packard ( ) or HP, was an American multinational information technology company headquartered in Palo Alto, California Palo Alto (; Spanish language, Spanish for "tall stick" ...

Hewlett-Packard
.


Requirements analysis issues


Stakeholder issues

Steve McConnell, in his book ''Rapid Development'', details a number of ways users can inhibit requirements gathering: * Users do not understand what they want or users don't have a clear idea of their requirements * Users will not commit to a set of written requirements * Users insist on new requirements after the cost and schedule have been fixed * Communication with users is slow * Users often do not participate in reviews or are incapable of doing so * Users are technically unsophisticated * Users do not understand the development process * Users do not know about present technology This may lead to the situation where user requirements keep changing even when system or product development has been started.


Engineer/developer issues

Possible problems caused by engineers and developers during requirements analysis are: * A natural inclination towards writing code can lead to implementation beginning before the requirements analysis is complete, potentially resulting in code changes to meet actual requirements once they are known. * Technical personnel and end-users may have different vocabularies. Consequently, they may wrongly believe they are in perfect agreement until the finished product is supplied. * Engineers and developers may try to make the requirements fit an existing system or model, rather than develop a system specific to the needs of the client.


Attempted solutions

One attempted solution to communications problems has been to employ specialists in business or system analysis. Techniques introduced in the 1990s like
prototyping A prototype is an early sample, model, or release of a product built to test a concept or process. It is a term used in a variety of contexts, including semantics Semantics (from grc, σημαντικός ''sēmantikós'', "significant" ...
,
Unified Modeling Language The Unified Modeling Language (UML) is a general-purpose, developmental, modeling language A modeling language is any artificial language that can be used to express information Information is processed, organised and structured data. ...
(UML),
use case In software engineering, software and systems engineering, the phrase use case is a Polysemy, polyseme with two Word sense, senses: # A usage scenario for a piece of software; often used in the plural to suggest situations where a piece of soft ...

use case
s, and
agile software development In software development Software development is the process of conceiving, specifying, designing, programming, documenting, testing, and bug fixing involved in creating and maintaining applications Application may refer to: Mathematics a ...
are also intended as solutions to problems encountered with previous methods. Also, a new class of application simulation or application definition tools have entered the market. These tools are designed to bridge the communication gap between business users and the IT organization — and also to allow applications to be 'test marketed' before any code is produced. The best of these tools offer: *
electronic whiteboard 2007 Image:Digibord klokkijken.jpg, A student uses the interactive whiteboard An interactive whiteboard (IWB), also known as interactive board or smart board, is a large interactiveAcross the many fields concerned with interactivity, including i ...
s to sketch application flows and test alternatives * ability to capture business logic and data needs * ability to generate high fidelity prototypes that closely imitate the final application * interactivity * capability to add contextual requirements and other comments * ability for remote and distributed users to run and interact with the simulation


See also

*
Business analysis Business analysis is a research List of academic disciplines, discipline of identifying business needs and determining solutions to business problems. Solutions often include a software-systems development component, but may also consist of proce ...
* Business Analysis Body of Knowledge (BABOK) *
Business process reengineering Business process re-engineering (BPR) is a business management strategy, originally pioneered in the early 1990s, focusing on the analysis and design of workflow A workflow consists of an orchestrated and repeatable pattern of activity, enabl ...
*
Creative brief A creative brief is a document used by creative professional A creative professional who is also known as a creative specialist is a person who is employed for the extraction of skills in creative endeavors. Creative professions include writing, ar ...
*
Data modeling Data modeling in software engineering Software engineering is the systematic application of engineering Engineering is the use of scientific principles to design and build machines, structures, and other items, including bridges, tu ...
*
Design brief A design brief is a document for a design A design is a plan or specification for the construction of an object or system or for the implementation of an activity or process, or the result of that plan or specification in the form of a prototype, ...
*
Functional requirements In software engineering Software engineering is the systematic application of engineering approaches to the software development, development of software. A software engineer is a person who applies the principles of software engineering to design ...
* Information technology *
Model-driven engineering Model-driven engineering (MDE) is a software development methodology that focuses on creating and exploiting domain models, which are conceptual models of all the topics related to a specific problem. Hence, it highlights and aims at Representatio ...
*
Model Transformation Language A model transformation language in systems engineering, systems and software engineering is a language intended specifically for model transformation. Overview The notion of model transformation is central to Model-driven engineering, model-drive ...
*
Non-functional requirements In systems engineering and requirements engineering, a non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. They are contrasted with function ...
*
Process architecture Process architecture is the structural design of general process systems. It applies to fields such as computers (software, hardware, networks, etc.), business processes (enterprise architecture, policy and procedures, logistics, project management ...
*
Process modeling The term process model is used in various contexts. For example, in business process modeling Business process modeling (BPM) in business process management Business process management (BPM) is the discipline in which people use various methods t ...
* Product fit analysis *
Requirements elicitation In requirements engineering Requirements engineering (RE) is the process of defining, documenting, and maintaining requirement In product development and process optimization, a requirement is a singular documented physical or functional nee ...
*
Requirements Engineering Specialist Group The Requirements Engineering Specialist Group (RESG) is a British Computer Society#Specialist Groups, Specialist Group of the British Computer Society. It runs events on all aspects of Requirements. Mission of the RESG The RESG's stated purpose ...
*
Requirements management Requirements management is the process of documenting, analyzing Analysis is the process of breaking a complexity, complex topic or Substance theory, substance into smaller parts in order to gain a better understanding of it. The technique has b ...
*
Requirements Traceability Requirements traceability is a sub-discipline of requirements management within software development and systems engineering. Traceability as a general term is defined by the IEEE Systems and Software Engineering Vocabulary as (1) the degree to whic ...
* Search Based Software Engineering *
Software prototyping Software prototyping is the activity of creating prototype A prototype is an early sample, model, or release of a product built to test a concept or process. It is a term used in a variety of contexts, including semantics Semantics (fr ...
*
Software requirements The requirement for a system are the description of what the system should do, the service or services that it provides and the constraints on its operation. The IEEE Standard Glossary of Software Engineering Terminology defines a requirement In ...
* Software Requirements Specification *
Systems analysis Systems analysis is "the process of studying a procedure or business Business is the activity of making one's living or making money by producing or buying and selling products (such as goods and services). Simply put, it is "any activity ...
*
System requirements To be used efficiently, all computer software Software is a collection of instructions Instruction or instructions may refer to: Computing * Instruction, one operation of a processor within a computer architecture instruction set * Computer p ...
*
System requirements specification A System Requirements Specification (SyRS) (abbreviated SysRS when need to be distinct from a Software Requirements Specification, software requirements specification (SRS)) is a structured collection of information that embodies the requirements of ...
*
User-centered design User-centered design (UCD) or user-driven development (UDD) is a framework of process (not restricted to interfaces or technologies) in which usability goals, user characteristics, Environment (systems), environment, tasks and workflow of a pro ...


References


Bibliography

* * * * * * *


External links

* Peer-reviewe
Encyclopedia Entry on Requirements Engineering and Analysis
* Defense Acquisition Universit
Stakeholder Requirements Definition Process
--
MIL-HDBK 520 Systems Requirements Document Guidance
{{DEFAULTSORT:Requirements Analysis Systems engineering * Business analysis pl:Wymaganie (inżynieria)#Analiza wymagań lub inżynieria wymagań