12 Jun

Requirements Gathering

Author: 
Time2Know
Requirements Gathering

 

“ Defining a process will not solve the problem. Living the process will.” 
~
Atanas Aladjov

This article is a precious part of the hybris Project Patterns series.

When a project is failing to deliver the promised feature-set or the expected quality we normally look at the Development team or the QAs to make accountable.

At the end, those are the last lines of the production factory and therefore, a first place to look for reasonable explanations.

Nevertheless, often, after digging under the surface of the development process, we realize that the QA has tested what had been expected and the developers have implemented what had been specified.

Hence, actually, what went wrong had happened long before the Developer touched the keyboard…

Problem

The prime reason for most failing hybris projects is a weak Requirements Gathering process – the activity, which is supposed to uniformly identify the Business’ needs and provide the “source of requirement’s truth” for the final delivery.

Guideline

Define and implement a strong requirements process in the project. Make sure you follow the selected process with care and discipline.

Related patterns

Client, hybris Functional Consultant, PIM Awareness, Workshop, Domain Methodology, Software Methodology, Glossary, Communication

 

The Importance of Requirements

With no exception, all Software Methodologies define the Requirements Gathering process as the most important one in crafting the fate of the soon-to-be software system. The reason is simple: this is the activity where we establish a foundation of the future solution; we exercise our knowledge of the business domain and define the expectations for success.

Consider this: A specification of one single requirement is used as a primary input for the follow up steps and deliverables in the software process. In practice, an individual requirement specification impacts a number of activities and artifacts, for example:

   

 

That is why creating requirements is a high-responsibility task, which can determine – to a large extend – the fortune of the project. Evidently, if – for one or another reason – we fail to provide this input the right way, soon we will find ourselves amidst unhappy Client, frustrated developers and demotivated testers.

On the other side of the scale, if we guarantee that this process runs smoothly, we enable the well-being of all consecutive activities and dependent artifacts.

This vision about the requirements and their effect on the whole development process should be shared with everyone involved in the project. For that, we usually hold a dedicated Workshop discussion with the Team and the Client about this topic, so that all parties can understand the importance of the Requirements and appreciate the consequences. 

In my opinion, this first discussion is one of the most important interactions where we set a common base for our mutual work and we learn how to value every next step in the long process to come. So, spending an hour to review the Requirements process proves to produce valuable long-term understanding and commitment from everybody. 

 

Why is it Hard to Have a Grip on the Requirements Process?

The answer lies in the nature of the requirements and the ability of people to make the requirements “good enough to implement”.

Let us have a quick look at the process.

Commonly, the Client provides a list of needs at the start of the project. This list is usually written in a free prose, possibly containing vague statements and unclear benefits. Here are few examples:

“The system should support logging functionality”.

“Import of data could happen in regular intervals”.

The new mobile platform must support all features of the current system”.

 

It would be hard even for the most experienced development team to implement software, based on this input. Thus, it is the role of the Functional Consultant to understand the raw requirements and turn them into clear statements. This effort will result in valuable business features and implementable software.

Possible clarifications on the above statements can result in requirements like:

“A registered user must be able to login.”

“The system should offer an import process of products from ERP, running every 2 hours.”

The new mobile platform must support existing features, namely X, Y and Z”

Therefore, refining the requirements by adding users, making precisions and writing in active voice improves significantly the comprehension. The corrections made so far are more than visible, but is this clarification really enough to start building software?  

Not yet! 

Even if we employ best practices in defining requirements, we still miss details, benefits, expectation conditions, workflows and exceptional scenarios that can influence the outcome of each desirable feature.

And – indeed, the Devil is in the details! The details are where most of the projects collapse. Getting right the details seems to be a giant mountain to climb for most project teams.

In answering this challenge, consider approaching the Requirements Gathering process in 3 key steps:

  1. Identify high-level functional themes
  2. Identify implementable units of work for each functional theme
  3. Provide details for each implementable unit

Let us inspect each step in depth…

Step 1: Start with the Big Picture

Identify high-level functional themes and cluster all business needs into larger logical groups, like Functional and Non-functional Blocks. Note that this exercise requires certain experience in constructing hybris solutions.

The identification of those blocks could be feature-driven and follow a certain End-User experience (like registration process, checkout process) or be based on common digital-commerce practices.

 

During the initial requirements discovery phase, my first step would be to map the list of Client’s requirements to larger functional themes, called also “high-level Use cases” or “Epics” (in the Agile practices).

Simultaneously, I would employ our e-Commerce Domain Methodology to cross-check, whether the desired feature-list is compatible with contemporary standards and trends.

This not only allows me to grasp the “big picture”, but also to discover if there are significant gaps in the listed requirements, which would prevent the creation of a decent solution.  

Here is a mind map of a possible requirement grouping for front-end features in a B2C website:

   

And here is a suggestive mind-map for MDM / PIM back-office processes:

 

   

 

Terminology used for the requirements is essential. Therefore, make use the project Glossary when working with requirements, in order to ensure the proper use of definitions and concepts.

Step 2: Identify Implementable Units

After the high-level logical split, the next step is to identify smaller implementable units of work, which can be offered to the Development team for realization.

The implementable unit should deliver concrete business value and offer measurable success criteria.

In our projects we define requirements directly in the form of Agile user stories. A user story is a simple coherent description of a feature, expressed from a User point of view, to identify a certain capability of the system.  

When writing user stories we comply to the Bill Wake’s INVEST principle, namely, that the user story should be:

  • I – Independent: self-contained, in a way that there is no inherent dependency on another user story.
  • N – Negotiable: up until they are part of an implementation iteration, can always be altered, exchanged and rewritten.
  • V – Valuable: must always deliver value to the end user of the feature.
  • E – Estimable: one should always be able to estimate the effort behind the implementation of a user story.
  • S – Small: small enough as to become possible to plan and prioritize with a decent level of certainty.
  • T – Testable: must provide the necessary information to make test development possible and measurable.

This approach already offers the advantage of considering the major implementable units, which would conform to the Client’s requirements – with a proper level of confidence that we have not missed significant functionality. 

 

Hence, during the identification of the implementable units, ask yourself:

  • What is the added value of the feature?
  • Is it understandable and clear?
  • For who is it important and who will use it?
  • Who will administer it?
  • How can we test it?
  • Does it depend on other features?

Those techniques are thoroughly described by most of the Software Methodologies, hence the point here is:

Do not forget them. Employ your knowledge into simplicity and clarifications. 

 

Step 3: Zoom Into the Details

Regardless if you are using traditional S.M.A.R.T. Use Cases or Agile User Stories, make sure that for each requirement you define two elements – Details (sufficient elements, which can be implemented) and Confirmation (acceptance tests that validate it).

Questions like “Why?”, “Who?”, “What?”, “When?”, “Where?” and “How?” usually help the discussions with the Business Client to solicit the relevant Details.

Even though details can be written in any format or shape, in the context of hybris projects, I use dedicated templates for describing various types of features, such as Back-Office-, Integration- and Non-Functional features.

Templates guarantee consistency in style and structure, when defining requirements. They summarize all essential facets of a good requirement and therefore, can serve as a valuable jump-start for new consultants or project members.

Moreover, the templates act as a checklist to remind us to recall important requirement’s aspects in the complex hybris project setting.

Here is an example of a template I use for detailing Front End features:

 

Details should provide confidence for implementation, so that the technical team would have an easier job to further proceed with technical estimation, planning and development.

 

When Are We Done?

As part of drafting the details, do not forget the Confirmation aspect, namely: identify and write the success conditions of your implementable units. 

Remember that these conditions are, in fact, the only credible source of information that ensures that we have met the expectations of the Business Client. Everything else is simply a text. Thus, writing the Acceptance success criteria is a way to perform a mini Expectation Management for each requirement. Success criteria will form the base for the future Test Cases, which will measure the final quality of each delivered feature.

Agile practices, like Scrum and Kanban, have a notion of “Done”.

The Definition of Done (DoD) represents a simple list of activities – like writing code, adding comments in code, unit testing, supplying design documents, and so on – that represent a demonstrable result of a feature.  

An example of DoD can be seen below. Note that done-ness is more than a formality – it is a contract, a high-level commitment, which your entire team makes towards the Client, regarding quality and deliverables.

There is no perfect list for Done – the commitment depends on your team, situation and maturity to deliver.

 

With well-described Details and Confirmation, you can safely offer a requirement to the development team. The level of clarity and specifics in the provided details should be sufficient for transforming the requirement into a valuable software business feature. 

 

Make Use of Your Domain and Software Methodologies

The Requirements Process should be an integral part of the selected – for the project – Domain- and Software Methodologies.

Employing a Software Methodology would bring along a corresponding Requirements Gathering process. Make sure you actually use this process in your project, if you wish to succeed.

Complementary, having a Domain Methodology would help you immensely with the identification of implementable units, thus saving you time and efforts. The domain know-how and know-why would give you a complete grid of functionality that is required by a common e-commerce project.

A final word: Defining the process will not solve the problem. Living the process will.

After agreeing on the requirement process, start executing it from the first project days. Be diligent and consistent - soon your efforts will be highly rewarded and capitalized.

 

 
  Continue reading:

 


 Do you share similar experience? Do let us know ...  

 

Total votes: 0