What is a Requirement?
One of the most critical aspects of Software Product Management deal with conditions known as
requirements. Many definitions have been developed to describe “requirements.” A requirement is most easily understood as a specific description of your client’s needs, which can be used to help create a real-world product.
The Institute of Electrical and Electronics Engineers (IEEE) defines a requirement as:
1. A condition or capability needed by a user to solve a problem or achieve an objective.
2. 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 documents.
3. A documented representation of a condition or capability as in (1) or (2). (IEEE, 1990). Well-defined requirements help make sure client needs are understood and addressed and also
help detect potential problems before they become large and expensive to fi
Requirements Activities
Requirements are established during activities at the beginning of a project. It determines the purpose of a product and how the product can meet that purpose.
This course will explore five important requirements activities:
1. Eliciting requirements
2. Expressing requirements
3. Prioritizing requirements
4. Analyzing requirements
5. Managing requirements
With these activities, the right requirements can be established, written in proper form, and even improved
Eliciting Requirements
The activity of eliciting requirements is an interactive and investigative process, which occurs when meeting with the client and users.
Clients often have ideas about what features they would like in a product and what these features should look like. Many clients, however, have limited knowledge of how software is built and vague ideas regarding what makes a project successful. It can be difficult then for clients to understand what they truly require in a product. It is the role of the software product manager to help the client figure out what they “want” and what they “need.”
A “want” is usually a functionality or feature that the client would like the product to have, which may add value, but is not necessarily core to the product itself. A “need,” on the other hand, is a core functionality that the product must have in order to fulfill the product’s purpose. Needs should take priority in product development.
The best way to discover and develop “needs” and “wants” with your client is through eliciting requirements, where you engage in discussion about the product with your client. Through discussion, the software product manager and team can help provide insights on what the client “needs” and “wants” the product to do, and how these goals can be feasibly achieved. It may be that the initial vision the client had of the product will have changed, but through involvement with the software product team, any changes should feel proactive and the client should feel reassured that the team understands users’ needs.
Note that eliciting requirements as “needs” and “wants” does not necessarily mean that all the client’s features and ideas that fall in the “want” category are not doable or should be dismissed. In fact, these ideas may be very good. But it is the role of the software product manager to make sure that the goals are feasible, client expectations are realistic, and the product produced is the best possible result.
Eliciting requirements should not be confused with “requirements gathering.” “Requirements gathering” is the more passive approach of simply asking the client what they would like done, and it often puts the development team in a reactive process. Eliciting requirements, however, engages in in-depth discussion and collaboration from the start of product development, so both the client and the development team work together to build a successful product.
Expressing Requirements
Once client needs have been established by eliciting requirements, the activity of expressing requirements comes into play. Expressing requirements involves framing the requirements identified through discussion in a way that allows a product to be built.
Often, requirements are first described through notes from meetings with clients. From there, better and more concrete representations can be used for expressing requirements. Typical representations include use cases, user stories, or storyboards, among others. These are often tailored to the project. They could be simple or complex, textual or visual. It is up to the software product manager and team to determine and use representations that would work best for the project at hand.
Prioritizing Requirements Once a vision of what needs to be done for the project has been established through both eliciting and expressing requirements, it is important to prioritize client needs, especially in Scrum methodology.
Questions to help establish priorities include:
- What requirements must be completed for the project and product to be successful?
- What requirements should be done? In other words, what is important but is not as time-critical or could be satisfied another way or at a later time on the project?
- What could be done to improve the project or product but is not necessary?
These priorities are usually only included if both time and resources allow for it.
Analyzing Requirements The process of examining the listed requirements of a project to ensure that they are clear, complete, and consistent is known as analyzing requirements. Analyzing requirements helps ensure that the product is the best one possible. It is an important process, and a constant one. A project must be continually evaluated and requirements improved as it progresses. This adaptive nature is important in Agile systems.
MORE INFORMATION
The questions outlined here closely follow the MoSCoW method of prioritization, developed by Dai Clegg. This method is used to help reach an understanding with clients on the importance of each requirement. “MoSCoW” is an acronym for the categories of “Must have”, “Should have”, “Could have” and “Would like but won’t get.” By asking the questions suggested here, requirements can be placed in these categories.
Analyzing requirements
The process of examining the listed requirements of a project to ensure that they are clear, complete, and consistent is known as analyzing requirements. Analyzing requirements helps ensure that the product is the best one possible. It is an important process, and a constant one. A project must be continually evaluated and requirements improved as it progresses. This adaptive nature is important in Agile systems.
Analyzing requirements helps to resolve any potential conflicting requirements or to identify problems between requirements that might not be easily seen at first glance. It also ensures that the requirements identified truly reflect and relate to the product being built.
Managing Requirements
The activity of managing requirements is also a continuous process. It involves the organizing and re-organizing of requirements and possibly reusing subsets of requirements in different stages. It also involves keeping track of priorities, analyses, and changes in requirements. This is very important because everything is connected in a project. If something changes in one requirement, it will affect other requirements and the development of the product.
Managing requirements also means ensuring that the identified requirements are central to the many processes of product creation, including coding, testing, and change logs.
Types of Requirements
Now that we’ve covered what requirements are and the activities involved with getting them right, let’s dive into a little more detail and introduce some different types of requirements.
- Business requirements
- Business rules
- User requirements
- Functional requirements
- Non-functional requirements
- External interfaces
- Physical product settings
- Development constraints
While business requirements and business rules can influence the project, it’s user requirements, functional requirements, and non-functional requirements that are considered the most essential requirements. Finally, external interfaces, physical product settings, and development constraints are requirements that add context for design and implementation of the product
