Requirements gathering is an essential part of any project, but it can easily become a challenging endeavour. This article focuses on some common problems when gathering requirements and suggestions on how to overcome them. Show
Undocumented processesIn many organisations there is often no or very poor documentation available about existing processes. In this situation, requirements gathering becomes a two-step process. Firstly, back-engineering of existing process, and then identifying areas for improvement and optimisation. To ensure requirements are full and correct, it’s critical to identify key stakeholders and subject matter experts and engage with them directly. This helps eliminate any assumptions and provides a full picture. Drawing business process maps and visualising workflows are effective techniques that can be used in this situation. Conflicting requirementsUncertainty about exiting process or different priorities for different stakeholders, often leads to conflicting requirements. If this is the case, the role of a business analyst is to document all requirements, identify contradictory requests and let stakeholders decide on priorities. As a business analyst you may have some recommendations about what should be prioritised, but it’s still important to hear stakeholders’ opinion. Setting up a poll can be one of the ways to get clarity about what is important to the majority of stakeholders. Lack of access to end usersUnavailability of end users may occur due to a few reasons and requires appropriate resolution. Sometimes end users are too busy with their day-to-day work and unwilling to participate in requirements gathering activities. In such situations the best a business analyst can do is to minimise the number and length of engagements. Doing as much research as possible prior to the engagement will help to make the conversation more structured and insightful. It is almost like turning requirements gathering into requirements validation sessions. Defining focus groups and finding the most suitable end-users in each group will also help. Another common scenario is when IT or the project team ‘know’ what end-users want and discourage direct communication. To convince the team about the necessity of such engagements, try identifying and presenting examples of day-to-day tasks and problems that different users may encounter. Spotlight the differences, the environment they are working in, KPIs they have, technology they are using, etc. Such details often uncover unique requirements that could not be assumed or revealed by one group of users. Focusing on visual aspects rather than on functionalOften stakeholders and end-users have a clear picture of how the new solution should look but don’t have understanding of what it should do. The user interface is an important aspect of any system, but it should not define or hinder the functionality. Business analyst should make sure there is a clear distinction between design and functional requirements in their documentation. To keep focus on functional aspects use more abstract tools such as diagrams, user stories and low-fi prototypes rather than design drafts. Stakeholder designThis is the case when the stakeholders or end-user have the urge to dictate how the system should work rather than providing details about what the system should do. Listening to stakeholders about potential solutions can be insightful but may also divert from actual problems and better solution designs. To prevent such situations, validate each potential ‘false requirement’ by asking ‘why?’, eventually it will reveal the ‘true’ requirement. Communication problemsThis category included language barriers, wrong assumptions, unclearly defined vocabulary, and excessive use of professional terminology that can lead to misunderstandings between stakeholders and a business analyst. The best strategy to avoid such situation is to communicate often and establish two-way communication. Document gathered requirements and send them for review and feedback to multiple subject matter experts, create and share a glossary of terms, and always verify assumptions. In summaryThese are just some of the challenges of the requirements gathering process. Being able to identify these challenges and manage them appropriately is the key to overall project success. A comprehensive set of requirements is crucial for any software project. Requirements identify the product's business needs and purposes at a high level. They also clarify the features, functionality, behaviors and performance that stakeholders expect. Software requirements are a way to identify and clarify the why, what and how of a business's application. When documented properly, software requirements form a roadmap that leads a development team to build the right product quickly and with minimal costly rework. The actual types of software requirements and documents an IT organization produces for a given project depend on the audience and the maturity of the project. In fact, organizations often draft several requirements documents, each to suit the specific needs of business leaders, project managers and application developers. Let's start with a look at several different types of requirements in software engineering:
Then, explore common types of software requirements documentation, as well as tried-and-true characteristics to help define requirements.  Business requirementsBusiness needs drive many software projects. A business requirements document (BRD) outlines measurable project goals for the business, users and other stakeholders. Business analysts, leaders and other project sponsors create the BRD at the start of the project. This document defines the why behind the build. For software development contractors, the BRD also serves as the basis for more detailed document preparation with clients. A BRD is composed of one or more statements. No universally established format exists for BRD statements, but one common approach is to align goals: Write statements that match a project goal to a measurable stakeholder or business goal. The basic format of a BRD statement looks like: "The [project name] software will [meet a business goal] in order to [realize a business benefit]." And here's a detailed BRD statement example: "The laser marking software will allow the manufacturing floor to mark text and images on stainless steel components using a suitable laser beam in order to save money in chemical etching and disposal costs." For this example, the purpose of the proposed software project is to operate an industrial laser marking system, which is an alternative to costly and environmentally dangerous chemicals, to mark stainless steel product parts. Organizations prepare a BRD as a foundation for subsequent, more detailed requirements documents. Ensure that the BRD reflects a complete set of practical and measurable goals -- and meets customer expectations. Finally, the BRD should be a living document. Evaluate any future requirements, updates or changes to the project against the BRD to ensure that the organization's goals are still met. User requirementsUser requirements reflect the specific needs or expectations of the software's customers. Organizations sometimes incorporate these requirements into a BRD, but an application that poses extensive user functionality or complex UI issues might justify a separate document specific to the needs of the intended user. User requirements -- much like user stories -- highlight the ways in which customers interact with software. There is no universally accepted standard for user requirements statements, but here's one common format: "The [user type] shall [interact with the software] in order to [meet a business goal or achieve a result]." A user requirement in that mold for the industrial laser marking software example looks like: "The production floor manager shall be able to upload new marking files as needed in order to maintain a current and complete library of laser marking images for production use." Software requirementsAfter the BRD outlines the business goals and benefits of a project, the team should devise a software requirements specification (SRS) that identifies the specific features, functions, nonfunctional requirements and requisite use cases for the software. Essentially, the SRS details what the software will do, and it expands upon or translates the BRD into features and functions that developers understand. Software requirements typically break down into:
Functional requirements. Functional requirements are statements or goals used to define system behavior. Functional requirements define what a software system must do or not do. They are typically expressed as responses to inputs or conditions. A functional requirement can express an if/then relationship, as in the example below: If an alarm is received from a sensor, the system will report the alarm and halt until the alarm is acknowledged and cleared. Functional requirements may detail specific types of data inputs such as names, addresses, dimensions and distances. These requirements often include an array of calculations vital to the software working correctly. Functional requirements are relatively easy and straightforward to test because they define how the system behaves. A test fails when the system does not function as expected. Nonfunctional requirements (NFRs). Nonfunctional requirements relate to software usability. Nonfunctional software requirements define how the system must operate or perform. A system can meet its functional requirements and fail to meet its nonfunctional requirements. NFRs define the software's characteristics and expected user experience (UX). They cover:
An example nonfunctional requirement related to performance and UX could state: The pages of this web portal must load within 0.5 seconds. Domain requirements. Domain requirements are expectations related to a particular type of software, purpose or industry vertical. Domain requirements can be functional or nonfunctional. The common factor for domain requirements is that they meet established standards or widely accepted feature sets for that category of software project. Domain requirements typically arise in military, medical and financial industry sectors, among others. One example of a domain requirement is for software in medical equipment: The software must be developed in accordance with IEC 60601 regarding the basic safety and performance for medical electrical equipment. Software can be functional and usable but not acceptable for production because it fails to meet domain requirements. Examples of software requirementsAn SRS often describes the software as a series of individual functional modules. In the laser marking software example, an SRS could define these modules:
There are some industry standards for an SRS, such as ISO/IEC/IEEE 29148-2018, but organizations can still use a different preferred format for SRS statements. Here's one common approach: "The [feature or function] shall [do something based on user inputs and provide corresponding outputs]." And here are a few software requirements in the laser marking system: "The laser marking operation shall translate AutoCAD-type vector graphics files into laser on/off control signals as well as X and Y mirror control signals used to operate the laser system." "The software provides a visual feedback to the operator, who shall track and display the current state of the marking cycle overlaid on a graphic product image displayed on a nearby monitor in real time." In addition to functional requirements, an SRS often includes nonfunctional requirements that identify attributes of the system or the operational environment. Nonfunctional requirements include usability, security, availability, capacity, reliability and compliance. They dictate development decisions and design requirements for the software, like password change frequency, data protection settings and login details. A systems analyst or product manager typically puts together an SRS in collaboration with relevant stakeholders, such as the developer staff. Ideally, every requirement delineated in an SRS should correspond with business objectives a BRD outlines. For third-party software contractors, the completed SRS provides the basis for cost estimation and contract compliance. While the SRS typically includes functional and nonfunctional requirements, some organizations might differentiate between an SRS and a functional requirements specification (FRS). In these cases, the FRS serves as a separate document and delves into the how of a software product. An FRS often stipulates all of the fields and user interactions throughout the entire software product. Characteristics of good software requirementsAll types of software requirements require significant prep work as part of the product development process. Additionally, such efforts force organizations to think about why to undertake a project, what the software product should provide, and how it will accomplish the desired goals. Requirements documents are a foundation upon which teams conceive, propose, budget and implement a software development project. Have software requirements embody the following seven characteristics. Clear and understandable. Software requirements must provide the utmost clarity. Write requirements in plain language, free of domain-specific terms and jargon. Clear and concise statements make requirements documents easy to evaluate for subsequent characteristics. Correct and complete. The document should accurately detail all requirements. If it's a BRD, the document should detail all business goals and benefits. If it's an SRS, it should describe all features and functionality expected from the system. Use an easily readable format and go back to finish any to-be-determined entries. It rarely falls on one person to deliver a correct and complete software requirements document. Involve all relevant parties -- business leaders, project managers, development staff, customers -- in careful and ongoing requirements collaboration. Consistent, not redundant. Software requirements documents are often long and divided into multiple parts -- each with its own specific requirements. Consistent requirements have no conflicts, such as differences in time, distance or terminology. For example, the difference between server and system will confuse some team members, so use only one to refer to the physical machine in the data center running the software. Only state a requirement once; don't duplicate it. Redundant requirements often lead to errors if, in the course of the project, the team changes or updates an iteration and the manager forgets to change or update repeated entries elsewhere in the document. Unambiguous. No software requirement can leave room for interpretation. Even clear statements can still be subject to multiple interpretations, which leads to implementation oversights. For example, it might be clear to require that a function, like a mathematical process, should be performed on a temperature measurement, but a requirement must specify the temperature measurement as degrees in Fahrenheit, Celsius or Kelvin. Phrase each statement so that there is only one possible interpretation. Collaboration and peer reviews help ensure unambiguous requirements documentation. Design-agnostic. Software requirements documents should illustrate an end result. Like an architectural diagram, the different types of requirements together detail what the development team should build and why, but rarely explain how. Empower developers to select from various design options during the implementation phase of the software project; don't stipulate specific implementation details unless they're necessary to satisfy business goals. A business might, for example, prohibit developers from using open source components in a project, as the approach conflicts with its ability to sell or license the finished project. Measurable and testable. The goal of a requirements document is to provide a roadmap for implementation. Eventually, teams must evaluate a completed project to determine whether the effort is successful -- for this, they must be able to objectively measure statements. As an example, a requirement like, "must start quickly" is not measurable. Instead, use a quantifiable requirement such as, "must initialize and be ready to accept network traffic within five seconds." This characteristic is particularly important for work done by software subcontractors, as unmeasurable statements can lead to cycles of costly rework. Prepare a software requirements document with testing in mind. Each statement should enable the team to create test plans and test cases that validate the completed build. Traceable. It's hard to know when developers are actually done with a software project. Ideally, there will be a direct connection between requirements documents and finished code; a project manager should be able to follow the provenance of a project from a requirement to a design element to a code segment, and even to a test case or protocol. When a requirement does not trace to the finished code, the development team might not implement it, and the project could be incomplete. Code that is present without a corresponding requirement might be superfluous -- or even malicious. Conversely, when a project manager sees all requirements reflected in the finished code and it passes testing, the project is complete. Why is it difficult to determine correct and complete requirements?Identifying requirements is difficult because it requires nearly a perfect storm of the correct process, involvement of the correct people for the business problem to be solved (before it is even defined) and an environment that is conducive to making all of the parts work together.
What are the 4 types of requirements?The main types of requirements are:. Functional Requirements.. Performance Requirements.. System Technical Requirements.. Specifications.. What makes requirements gathering difficult?Stakeholders have Conflicting priorities
The requirement gathering process requires having tough, open ended questions for the stakeholders to answer. Stakeholders need time to fully articulate their ideas and perspective.
What causes a poor understanding of user requirements?Among the main reasons for poor user requirements are (1) an inadequate understanding of the intended users and the context of use, and (2) vague usability requirements, such as “the system must be intuitive to use.”
|
