Qualified

Requirement definition

A customer's definition of requirements might sound like a high-level product concept to the developer. The developer's notion of requirements might sound like detailed user interface design to the user. This diversity of definitions leads to confusing and frustrating communication problems.

TIP

A key concept is that the requirements must be documented.

A condition or capability needed by a user to solve a problem or achieve an objective.
A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.
A documented representation of a condition or capability as in 1 or 2.

Requirements

Requirements are a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute. They may be a constraint on the development process of the system.

Требование - некое свойство программного обеспечения, необходимое пользователю для решения проблемы при достижении поставленной цели.

Требование - свойство программного обеспечения, которым должна обладать система или ее компонент, чтобы удовлетворить требования контракта, стандарта, спецификации либо иной формальной документации.

Управление требованиями - это систематический подход к выявлению, организации и документированию требований к системе, а также процесс, в ходе которого вырабатывается и обеспечивается соглашение между заказчиком и выполняющей проект группой по поводу меняющихся требований к системе.

requirements-management

Levels of Requirements

Business

defines the business problems or opportunities about the product. Business requirements define why the software product is being developed. They are the objectives of the customer requesting the development of the software.

Business requirements describe why the organization is undertaking the project. They state some benefits that the developing organization or its customers expect to receive from the product. Business requirements may be delineated in several documents such as a project charter, business case, or in a project vision and scope statements. Business requirements bring the project owner, stakeholders and the project team on the same song sheet. But you can’t build software from such high-level information.

Problem Statement
Project Vision
Project Constraints (Budget, Schedule, and Resources)
Project Objectives
Project Scope Statements
Business Process Analysis
Stakeholder Analysis

A business requirement is not something a system must do. It is something that the business needs to do or have in order to stay in business. For example, a business requirement can be:

a process they must complete
a piece of data they need to use for that process
a business rule that governs that process and that data

Your business requirements change less (in most businesses) than your functional requirements, and are typically more objective. “If we don’t find the best way to reach our customer, we could be out of business!” So, the business requirement would read something like: “We need to contact the customer with xyz information”, not “the system will….”.

Remember, “The system shall do this or that…” describes the how (or the functionality). It is the manifestation of the business requirement in a system.

Let’s consider if this had been stated as a user story.

As a Product Owner, I want to communicate product incentives to our customers each time they purchase a complimentary product.

In this instance, the user story is written independent of the how or functionality and is a business or stakeholder requirement. (Although, I might argue that it really doesn’t state the true benefit however and should be rewritten.) Too often, though, a user story will be written like this:

As a Product Owner, I want our customers to receive an automated email each time they purchase a complimentary product.

This is definitely a functional requirement and makes some huge assumptions regarding the purchase of products. Are they always made in an automated fashion, if not, how does the system know to send an automated email at the time of purchase and to what email address? What is the Product Owner is really trying to achieve? Is sending an automated email the best way to accomplish the ultimate goal?

Understanding the true problem or business need (Business Requirement) will ensure that you are delivering the highest value to your customer. Once we understand the true business needs, we can start determining the best way to approach building a solution (whether automation is involved or not) and how to implement that solution.

User

defines functionality of the software product from the user’s perspective. They define what the software has to do in order for the users to accomplish their objectives.

User requirements, often referred to as user needs, describe what the user does with the system, such as what activities that users must be able to perform. User requirements are generally documented in a User Requirements Document (URD) using narrative text. User requirements are generally signed off by the user and used as the primary input for creating system requirements.

An important and difficult step of designing a software product is determining what the user actually wants it to do. This is because the user is often not able to communicate the entirety of their needs and wants, and the information they provide may also be incomplete, inaccurate and self-conflicting. The responsibility of completely understanding what the customer wants falls on the business analyst. This is why user requirements are generally considered separately from system requirements. The business analyst carefully analyzes user requirements and carefully constructs and documents a set of high quality system requirements ensuring that that the requirements meet certain quality characteristics.

Functional requirements

define the software functionality must be built into the product to enable users to accomplish their tasks. This includes the entire external, database, functional/non-functional requirements.

Some of the more typical functional requirements include:

Business Rules
Transaction corrections, adjustments and cancellations
Administrative functions
Authentication
Authorization levels
Audit Tracking
External Interfaces
Certification Requirements
Reporting Requirements
Historical Data
Legal or Regulatory Requirements

Functional requirements provide a very detailed description of all of the functions your future product will have, how it should behave, and how it should respond to different user commands and gestures.

The functional requirements are mostly about how the system should act when the user interacts with it. How the login process should look like, what kind of information the user will be able to retrieve/have access to with what type of membership, what the user journey will be like, etc.

While there are different ways to write down functional specifications, one of the most popular ways is just by plain text. It is also common to draw a diagram to visually show the relationships between the user and the system but this approach has its drawbacks: it’s easy to misunderstand the issue or omit the context of the situation.

Today, there’re two key methods of creating functional requirements: through use cases and user stories.

When you describe requirements not as separate functions, but as a whole while considering the current context and simulating how users will interact with the entire system, you have a better chance to ensure the completeness and non-redundancy of requirements.

A regular use case should include:

Actors – Users that interact with a system.
System – The system that is built according to the specifications.
Goals – What makes user interact with a system and what they want to achieve as a final result.

Another way to structure functional requirements is by writing them in the form of user stories. User stories tend to better emphasize the end user and their goals. The typical structure of a user story looks as follows:

As a type of user, I want some goal so that some reason.

For example: As a user I want to have my Google account connected to my profile so that I will be able to log in with the Google account.

Every user story should be accompanied by the acceptance criteria that define the conditions the feature should meet/satisfy in order to be accepted by your product owner and stakeholders. One user story should have at least one acceptance criterion, each being testable and transparent to all of the stakeholders.

For example, the acceptance criteria for a login feature might be as follows:

User can use an email or a mobile phone number to log in;
The lengths of the password should be between 6 and 20 symbols;
Symbols in a password may include letters, numbers and special signs.

Most common requirements risks

Requirements risk is the potential for losses due to a project's requirements themselves or the requirements management process. Such risks are closely tied to the quality of requirements in that low quality requirements represent a risk to the project. Projects are garbage-in-garbage-out meaning that projects that are based on faulty requirements are likely to face issues and potentially fail. The following are a few common examples of requirements risk.

Missing Stakeholders The requirements management process fails identify or engage all stakeholders. For example, marketing is implementing a new product but sales isn't involved in the project.
Wrong Stakeholders Stakeholders who don't have the requisite knowledge, skills or authority to deliver, validate or sign off on requirements. For example, requirements gathering may be assigned to junior employees who have inadequate access to experts in the organization.
Ambiguous Requirements Requirements that are defined in such a way that they are open to misinterpretation. In some cases, stakeholders may intentionally define open-ended requirements in order to avoid making a decision or to protect themselves politically. In other cases, requirements are simply poorly worded. The user interface should be streamlined to improve productivity.
Incomplete Requirements Requirements that are incomplete leading to deliverables that are unstable, unusable or are generally unacceptable. For example, requirements for a system that make no mention of a user interface. Incomplete requirements can also refer to a set of requirements that are focused on functional requirements without adequate consideration of business and non-functional requirements.
Conflicting Requirements Requirements are often given by different individuals who each present a wishlist that may conflict in various ways. The owner of the requirements may fail to resolve such conflicts. Access to the system is restricted to authorized personnel in the HR department. A user interface allows all employees to enter their hours by activity code.
Infeasible Requirements Requirements that go well beyond the capabilities of the organization or system to which they apply. These risks can be mitigated with a quick feasibility or cost assessment. The car will go from 0 to 100 mph in 0.00001 seconds.
Big Ball Of Mud Requirements that lack overall consistency resulting in low quality deliverables. This is common when requirements are the result of ideas from many individuals without a strong owner who ensures a consistent high level cohesion. It can also be the result of validating requirements one-by-one without consideration of the requirements as a whole.
Unverifiable Requirements Requirements that have ill defined criteria for verification. The car will make people happy.
Undocumented Assumptions Requirements that only work given a set of assumptions that are undocumented. For example, the assumption that an organizational change will be in place in time for the project.
Invalid Assumptions Assumptions are often a major source of risk as they may be excessively optimistic or misinformed. The Hong Kong office will be fully functional by August 1st.
Business Requirements As Functional Requirements A business requirement that is stated as a functional requirement that fails to constrain the deliverables. In other words, a functional requirement that isn't directly actionable by those who are delivering the project. Sales will improve by 300%
Lack of Traceability Functional requirements that can't be mapped to business requirements, potentially invalidating the business case for the project.
Inadequate Validation Requirements that haven't been validated by the appropriate subject matter experts. For example, non-functional requirements for a new financial system that haven't been reviewed by a security analyst.

Characteristics of Excellent Requirements

Complete Each requirement must fully describe the functionality to be delivered. It must contain all the information necessary for the developer to design and implement that bit of functionality. If you know you're lacking certain information, use TBD (to be determined) as a standard flag to highlight these gaps. Resolve all TBDs in each portion of the requirements before you proceed with construction of that portion.
Correct Each requirement must accurately describe the functionality to be built. The reference for correctness is the source of the requirement, such as an actual user or a high-level system requirement. A software requirement that conflicts with its parent system requirement is not correct. Only user representatives can determine the correctness of user requirements, which is why users or their close surrogates must review the requirements.
Feasible It must be possible to implement each requirement within the known capabilities and limitations of the system and its operating environment. To avoid specifying unattainable requirements, have a developer work with marketing or the requirements analyst throughout the elicitation process. The developer can provide a reality check on what can and cannot be done technically and what can be done only at excessive cost. Incremental development approaches and proof-of-concept prototypes are ways to evaluate requirement feasibility.
Necessary Each requirement should document a capability that the customers really need or one that's required for conformance to an external system requirement or a standard. Every requirement should originate from a source that has the authority to specify requirements. Trace each requirement back to specific voice-of-the-customer input, such as a use case, a business rule, or some other origin.
Prioritized Assign an implementation priority to each functional requirement, feature, or use case to indicate how essential it is to a particular product release. If all the requirements are considered equally important, it's hard for the project manager to respond to budget cuts, schedule overruns, personnel losses, or new requirements added during development.
Unambiguous All readers of a requirement statement should arrive at a single, consistent interpretation of it, but natural language is highly prone to ambiguity. Write requirements in simple, concise, straightforward language appropriate to the user domain. "Comprehensible" is a requirement quality goal related to "unambiguous": readers must be able to understand what each requirement is saying. Define all specialized terms and terms that might confuse readers in a glossary.
Verifiable See whether you can devise a few tests or use other verification approaches, such as inspection or demonstration, to determine whether the product properly implements each requirement. If a requirement isn't verifiable, determining whether it was correctly implemented becomes a matter of opinion, not objective analysis. Requirements that are incomplete, inconsistent, infeasible, or ambiguous are also unverifiable (Drabick 1999).

Requirements Specification Characteristics

It's not enough to have excellent individual requirement statements. Sets of requirements that are collected into a specification ought to exhibit the characteristics described in the following sections.

Complete No requirements or necessary information should be absent. Missing requirements are hard to spot because they aren't there! Chapter 7 suggests some ways to find missing requirements. Focusing on user tasks, rather than on system functions, can help you to prevent incompleteness.
Consistent Consistent requirements don't conflict with other requirements of the same type or with higher-level business, system, or user requirements. Disagreements between requirements must be resolved before development can proceed. You might not know which single requirement (if any) is correct until you do some research. Recording the originator of each requirement lets you know who to talk to if you discover conflicts.
Modifiable You must be able to revise the SRS when necessary and to maintain a history of changes made to each requirement. This dictates that each requirement be uniquely labeled and expressed separately from other requirements so that you can refer to it unambiguously. Each requirement should appear only once in the SRS. It's easy to generate inconsistencies by changing only one instance of a duplicated requirement. Consider cross-referencing subsequent instances back to the original statement instead of duplicating the requirement. A table of contents and an index will make the SRS easier to modify. Storing requirements in a database or a commercial requirements management tool makes them into reusable objects.
Traceable A traceable requirement can be linked backward to its origin and forward to the design elements and source code that implement it and to the test cases that verify the implementation as correct. Traceable requirements are uniquely labeled with persistent identifiers. They are written in a structured, fine-grained way as opposed to crafting long narrative paragraphs. Avoid lumping multiple requirements together into a single statement; the different requirements might trace to different design and code elements.

Benefits from a High-Quality Requirements Process

Organizations that implement effective requirements engineering processes can reap multiple benefits. A great reward comes from reducing unnecessary rework during the late development stages and throughout the lengthy maintenance period. The high leveraging effect of quality requirements isn't obvious, and many people mistakenly believe that time spent discussing requirements simply delays delivery by the same duration. A holistic cost-of-quality perspective reveals the value of emphasizing early-stage quality practices

Engaging users in the requirements-gathering process generates enthusiasm for the product and builds customer loyalty. By emphasizing user tasks instead of superficially attractive features, the team can avoid writing code that won't ever be used. Customer involvement reduces the expectation gap between what the user needs and what the developer delivers. You're going to get the customer feedback eventually. Try to get it early rather than late, perhaps with the help of prototypes that stimulate user feedback. Requirements development takes time, but it takes less time than correcting a lot of problems in beta testing or after release.

Fewer requirements defects
Reduced development rework
Fewer unnecessary features
Lower enhancement costs
Faster development
Fewer miscommunications
Reduced scope creep
Reduced project chaos
More accurate system-testing estimates
Higher customer and team member satisfaction

Root Causes of Project Success and Failure

Three most commonly cited factors that caused projects to be "challenged":

Lack of user input: (13 percent of all projects)
Incomplete requirements and specifications: (12 percent of all projects)
Changing requirements and specifications: (12 percent of all projects)

Thereafter, the data diverges rapidly. Of course, your project could fail because of an unrealistic schedule or time frame (4 percent of the projects cited this), inadequate staffing and resources (6 percent), inadequate technology skills (7 percent), or various other reasons. Nevertheless, to the extent that the Standish figures are representative of the overall industry, it appears that at least a third of development projects run into trouble for reasons that are directly related to requirements gathering, requirements documentation, and requirements management.

Although the majority of projects do seem to experience schedule/budget overruns, if not outright cancellation, the Standish Group found that 9 percent of the projects in large companies were delivered on time and on budget; 16 percent of the projects in small companies enjoyed a similar success. That leads to an obvious question: What were the primary "success factors" for those projects? According to the Standish study, the three most important factors were

User involvement: (16 percent of all successful projects)
Executive management support: (14 percent of all successful projects)
Clear statement of requirements: (12 percent of all successful projects)

The two largest problems, appearing in about half the responses, were

Requirements specifications
Managing customer requirements

Again, corroborating the Standish survey, coding issues were a "nonproblem," relatively speaking.

# Qualified

# Requirement definition

# Levels of Requirements

# Business

# User

# Functional requirements

# Most common requirements risks

# Characteristics of Excellent Requirements

# Benefits from a High-Quality Requirements Process

# Root Causes of Project Success and Failure