Tuesday, 18 October 2016 08:55

Minimize Risk With Effective Requirements Gathering

Written by
Rate this item
(5 votes)
“We can only see a short distance ahead, but we can see plenty there that needs to be done.” - Alan Turing

Requirements gathering is the first step in any software development methodology, be it waterfall, agile, iterative or spiral. The essence of this step is to elicit and comprehensively capture the requirements from an actual customer who uses the product. These requirements could be captured in various forms such as use cases, user stories, wireframes, process models etc.

Most organizations have business analyst or product manager to gather requirements and communicate them to the technical team. Product managers also maintain the constant communication between the teams during the entire product lifecycle. Some companies also appoint third party facilitators.

Requirements gathering is such a critical step that according to IBM System Science Institute’s study, the relative cost of fixing the defect is the lowest if it occurs earlier in the product development cycle1.

Personally speaking, a requirements gathering exercise is a combination of art and science. The art lies in communicating and asking the right questions of the customer and deriving insights from customer’s pain points to lead to the development of detailed requirements. The science lies in capturing the requirements in a very cogent and legible way so that the they are easily understood by the development team.

Some of the steps that follow can be taken to effectively manage the requirements gathering process and aid in addressing issues early on in the product development process. These steps are more relevant from software industry perspective though these can be customized for other industries.

1. Apply design thinking principles to gather requirements

Design thinking is a human-centered approach to innovation that draws from the designer’s toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success2. Product managers are in a constant struggle to understand, prioritize and meet customer requirements. Design thinking can help them be in constant touch with their customers and design better, meaningful products for their users.

Empathy plays a critical role in the design thinking process where the product manager should step into the shoes of their users and understand their true needs. Applying design-thinking concepts can greatly improve the requirements gathering process resulting in products that rightly address the user’s need.

Rapid prototyping and sharing proof of concepts with the users can avoid surprises after products have been significantly developed.

2. Keep user context in mind

Sometimes product managers are so obsessed with functional requirements that they get the product right but the context wrong. For example, the product is developed on certain platforms, which may not be compatible in customer’s environment. A product compatible with the most recent version of Internet Explorer faces issues in Chrome or Firefox. Customers have to either upgrade/install browsers or have to maintain multiple browsers.

Another example is websites that are built for desktops viewing. When these are accessed on mobile devices, a part of the functionality does not work.

There are also cases where the applications are accessed via virtualization software. This may restrict functionality and and inhibit experience.

These issues could be avoided by understanding the environment in which the product would be used.

3. Collaborate with all stakeholders across the value chain

Addressing the needs of the customer is surely the key for building a great product. However, sometimes it makes sense to look sideways to gather requirements. For example, when one department hands over data to another department, there may be a gaping funcitionality hole. The requirements gathering process should address all the significant interactions between cross-functional teams and see where data migrations and handovers are happening. Even though these stakeholders would not be direct customers their requirements have an indirect impact on how the product would perform in a real world settings. Product managers should also seek feedback from within the team and leverage on their experience in building products.

4. Leverage cloud based tools

It’s so surprising that to date there are many companies that manage their requirements in Word documents and Excel sheets. Though these are wonderful tools there are several limitations with them in terms of version control, audit trail, and collaboration. They also don’t offer very rich visual dashboards. Reusability of various components also is a great impediment.

Cloud-based tools address these issues transparently at a much lesser cost. These tools are all the more important today as more products are shifting to agile methodologies where requirements have to be updated, added and modified in real time.

Cloud-based tools also have rich visual interfaces which help in tracing each requirement and delivery schedule. These tools help in maintaining a traceability matrix and change management process. Companies should consider using these tools for detail documentation and requirement-by-requirement collaboration.

5. Prioritize and perform competitive analysis

It is important that during the requirements gathering process product managers are aware of the customer priorities and share it with the development team. It is also the responsibility of the managers to keep close track of the competition and market knowledge as any changes in either could result in a change of priorities or revision in requirements – to which even the customer can be oblivious.

Requirements gathering is an extremely critical exercise that any error at this stage could lead to an unusable product, resulting in financial loss. Companies can customize and implement the above steps to ensure minimal lapses.

1 https://www.researchgate.net/publication

2 http://www.forbes.com/sites/sap/2015/05/10/what-is-design-thinking/#e01c8e63c187

Read 9057 times
Suraj	Chatrath

Suraj Chatrath is a experienced professional across product management and product development. He has extensive experience in requirement gathering, defining product roadmap, product strategy and translating business requirements into technical requirements. He holds an undergraduate degree in engineering and master’s degree in business management from Stanford Graduate School of Business where he was a Sloan fellow. Disclaimer: The views and opinions expressed in this article are those of the author and do not necessarily reflect the official policy or position of any company

Comments  

0 # Robin Goldsmith 2016-10-21 10:03
If you can "gather" them, then they are not requirements. They're probably design, which despite the techniques described in the article are likely to be wrong because they are not responding to the REAL requirements.
Reply | Reply with quote | Quote
0 # Steven Gordon, PhD 2016-10-22 11:39
In Agile, we are realistic about "requirements" - they often prove to have been incorrect once they have been implemented. There are many reasons for this, most of which have nothing to do with how they were "gathered".

The most important activity to reduce requirements risk is concrete validation. Implementing a thin vertical representative slice of the requirement and getting concrete feedback from users and stakeholders as quickly as possible is the key. This does not happen if you try to gather them all at once. Furthermore, miscommunicatio n patterns and misconceptions discovered in the validation of early requirements improves the gathering and understanding of subsequent requirements, so an iterative feedback-driven approach is critical to homing in on the actual requirements and building a good rapport with stakeholders and users.

An agile approach reduces risks much more than what you propose.
Reply | Reply with quote | Quote

Add comment

Security code
Refresh

search Articles

© BA Times.com 2016

DBC canada 250