Part I – Apply agile approach to gathering requirement process 

Introduction

The process of gathering the requirements for IT products is a real nightmare for project managers and disrupts the normal deployment of the product. This process takes place at the beginning of the whole product development project, when the idea of what is to be created resembles the mythical Loch Ness monster: no one has seen it, but everyone feels obliged to say something about it. The full effects of what is being done at this early stage will only be seen when the product actually goes live. However, the requirements defining process has a powerful impact on all stages of the software development process, i.e. on the analysis phase, architecture design phase, coding, and testing as well. It is important to stress that the key role in this process is played by people who are real experts in their fields. However, they do not necessarily know anything about software development and even if they know how to define their own requirements, they have a limited understanding of available technologies, system architectures or other aspects that have an enormous impact on the final result. 

Issues appeared during gathering requirements 

Two language issue. 

The language used by business stakeholders to describe their requirements is often natural, redundant, ambiguous and imprecise. The author may be convinced that the wording of the requirements is perfectly clear, but the other recipients or even the group of stakeholders that the author represents, may not. No to speak of developers who have to translate such requirements into the code. 

Provider Requirement Perspective issue 

Another aspect of requirements definition is the perspective from which it is made. In describing the requirements, stakeholders use their own perspective as other perspectives may be unknown to them, not fully understood or intentionally omitted for some reasons. 

Hidden assumption issue 

The requirements are created not only from the perspective of the stakeholder but also with certain hidden assumptions. Such hidden assumptions are strictly connected with the perception of the entire business reality and of the business processes that the product is supposed to support. These assumptions may be closely correlated with the business perspective of the requesters, their beliefs about the currently applied solutions that in the evaluator’s opinion work or should work in a predictable manner, and correlated only with the author’s subjective opinion or judgment, not necessarily with reality. What’s important to emphasize here are the key features of these hidden beliefs and assumptions: they are non-verbal and entirely unconscious. They are blindingly obvious to the point of not being worth any discussion. Someone may say: “I’m very surprised that anyone doesn’t know that”. With such hidden assumptions not being verbalized, the requirements are likely to be ambiguous or even misunderstood by others. 

In addition, cognitive errors such as generalizations, simplifications, distortions of perceived reality should also be taken into consideration. Errors appear at the stage of perception of the reality, including business reality, and are reflected in the descriptions of such reality. Thus, an incorrect perception of the reality is then reflected in the requirements. Therefore, the requirements need to be verified and corrected in a controlled manner. 

Abstraction of IT system issue 

Finally, the inherent characteristic of the IT systems comes into play. Systems are abstract. This means that they do not have any clear physical representation, as opposed to mechanical structures or buildings. They cannot be easily drawn or visualized. There is no established and widely accepted or commonly used method to describe them, neither. There are no clear units of measure. There are some attempts being made to standardize the description methods recommended by standardization organizations or developed by the most recognized in the IT environment private companies. Some of the examples of the graphical notation systems include BPMN / BMPL, BPEL or general-purpose system modeling languages such as UML. However, these systems and languages are mainly known and understood by the analysts. The rest of the participants of the IT product development process are not always capable of understanding in the correct and error-free manner what a particular schema shows. Notations means something else than the technical drawing for engineering does. The notations only try to do the same for design of IT products what the technical drawing for the engineering or building design does. Notations are merely a metaphorical way of presenting the abstract reality and processes implemented in the IT system. Graphical notations are very helpful at the requirements definition stage (as they say – one image is worth 1024 words), but at the same time the graphical representations of the abstracts have their limitations, and need to be understood and controlled. To create a good set of requirements it is not enough to use just the graphical notation of it. In addition, one can or even should utilize the best practice of the ISO/IEC/IEEE 29148: 2011 “Systems and software engineering – Requirements engineering” or the ISO/IEC 25000 “System and Software Quality Requirements and Evaluation”. It is worth remembering that they are only good practices and recommendations that should be adopted every time for a specific project in your organization. They certainly constitute the knowledge base for analysts or demand-side managers to help create a specific software engineering process for a particular piece of software in an organization. 

Managing the process of defining requirements in an agile manner 

The process of defining requirements should be able to cope with the nature of the phenomena that hinder the establishment of a list of good requirements. Irrespective of the applied IT project management methodology and regardless of whether it is a waterfall approach, an incremental development or agile methodology, the requirements development process should be iterative and interactive, basing on the Deming’s scheme (Plan-Do-Check-Act) and the agile software development practices. It should be emphasized that it is not about the agile management of an entire IT project delivery, but rather the use of some agile methodology components to create a good set of requirements. 

Here are the key elements in the process of creating requirements: 

• Commitment from the early stage to the work on requirements, not only by the stakeholders who submit requirements, but also by the members of the implementation team; 

• Cyclical analysis and development of submitted requirements – performed in fixed-length cycles where the analysis of the set of general requirements is successively done; 

• Improving and selecting of the requirements and creating a list of requirements to be ready for implementation. 

The general idea behind this approach can be concluded in this catchy sentence: Take control of the requirements before the requirements will take control of you. 

To take control of this complex, iterative process, you can take advantage of the agile project approach and adapt the Agile Project Management Model (APM Model) to the management of the whole IT software development, and apply it to the requirement management process only. 

For our purposes, we can call the adapted for requirement management APM model the IIRM Model (Interactive and Iterative Requirements Management Model). It runs in fixed-length cycles, lasting from a week to a few weeks, and consisting of the following stages: Vision, Planning of requirements, Development of Requirements. What should done during each stage were described below. 

Vision 

Before we start focusing on the vision, the crucial issue is to identify the right group of stakeholders and to map their roles to the RACI matrix (Responsible-Accountable-Consulted-Informed). The assignment of responsibilities will enable the implementation team to control the stakeholders’ responsibilities and ultimately deliver the best results, as expected by the stakeholders. 

When the vision is being created, the stakeholders (and particularly the product owner) should focus on establishing the first general framework enabling everybody to understand the essence and the key functions of the project. At this stage the requirement identification level can be general, however the key functional elements of the final solution should already be identified. 

The general framework of a vision includes: 

• Business objectives, i.e. what business processes the product should support, what is the product to facilitate or provide in the context of the said processes; 

• Product quality objectives, i.e. the scale, availability, responsiveness of the project, the number of clients served, the number of simultaneous employees, the number of simultaneous operations; 

• Design constraints defined in terms of time and resources needed to implement the project. We are talking primarily about financial resources. Of course, one can also point to non-financial resources as long as they are necessary to implement the project and should be identified at this stage, such as specific knowledge or technology or license. 

Planning of requirements 

At this stage, the stakeholders have a chance to report their requirements. 

It is important to emphasize that the list of requirements does not have to be complete, the requirements need not be detailed, they even better be general at this stage. It is desirable that the requirements reported be linked to the business processes mentioned in the Vision. 

It would be advisable to have the requirement defined in a simple interaction diagram with the action-reaction-effect scheme. An action in a role-defined process in the system – a reaction of the system. Let’s give a simple example for clarification: 

• role in the process: a seller 

• my action within my system role: I add a new client to the system 
• system response (optional): the system confirms to me the operation of adding a client to the system 

At this stage, we do not define what the customer means here, what its characteristics are, nor what the “add” action in this context means. This will be done at the stage of requirements development. 

The Requirements Plan creates a set of Product Backlogs that will be further refined and defined in the next step in our IIRM Model. 

Development of requirements 

The development of requirements begins with their analysis. In requirements analysis, all visualization methods derived from UML or BPMN/BPML or BPEL notations are helpful. Graphical requirements for processes, data flows, machine states, architecture, will not only better define the requirements – they will also allow them to understand their structure, to discover their true complexity, and to understand the underlying assumptions behind the rigorous requirements they have prepared. What is more important at this stage is not so much the precision of defining the requirements, but rather their full understanding by the reporters, analysts and representatives of the implementation team. Direct communication, interactive sessions, closely co-operating multidisciplinary teams, engaged stakeholders and implementation team (or its representatives), are crucial for the good outcome of this and further stages. 

The more the waterfall approach to the whole IT project is applied, the more precisely the requirements should be described. If our approach is more agile, that would be just the first run, and the level of detail would be adapted to the current approach. 

The outcome of our analytical work will lead us to redrafting, splitting, merging, grouping or even eliminating the inbound requirements. One of the results will also be the determination of the importance of the requirements for the whole product in the light of the vision and the timing of implementation of the requirements based on the initial assessment. 

If the requirement meets certain parameters, it may be assessed according to a particular criterion and eventually moved to the deployment phase or to the next stage, if our methodology is more agile. Now, we have two possible paths. 

Update … 

If the requirement does not meet the assessment criteria, it should be updated to the extent that it can be improved in a given cycle and remain in the process for further development within the next process cycle. At this stage, some guidelines may be created for updating the vision or the project framework. 

… or forwarding of the requirement to the deployment phase 

The requirement goes into the deployment phase if it is correctly defined during the IIRM Model cycle. The criteria for the proper definition of requirements can be depicted by one mnemonic word: “INVEST”, proposed by Bill Wake, and originally used only for agile projects. The criteria can also be applicable with some modifications in other types of projects. 

INVEST is a mnemonic describing the characteristics of well-defined requirements. Individual letters of the acronym break out as follows: 

I – Independent – the requirements should not be dependent on other requirements or these dependencies should be as limited as possible. What dependency means here is that the commencement of work for a particular requirement requires the completion of work for another requirement. It is important to minimize inter-dependencies, not necessarily reducing them to null, but rather stick to the rule that the less is better in this case. 

N – Negotiable – i.e., the proper level of description depending on the design methodology of the entire product production; a description that allows you to understand what a given story is. In agile approaches, conducting a feature is being understood in the context of description flexibility. We define the necessary minimum because the requirement will continue to live in the software development cycle, and a certain amount of flexibility is essential. The requirement must be described in such a way that it can be modified at the later stages. In projects of a more waterfalling nature, this feature means that the description of the requirement should be designed precisely enough and its appearance should be well-founded, meaning properly anchored in the vision, in the business processes. All schemes and descriptions of the processes to which the requirement is linked, and those which have emerged at the requirements analysis stage, increase the negotiability of such a requirement. 

V – Valuable – The requirement should present a value for the stakeholders, expressed in terms of the value as assessed by the stakeholders themselves. Most often, the value is the anticipated business benefit in the form of customer cash streams, the leads reducing business process execution or the reduction of cost of operations. 

E – Estimable – the requirement should be defined so as to enable the implementation team to evaluate the cost of the implementation of such requirement. A coherent assessment of the implementation time, complexity, and a number of resources needed for the implementation team, can be parts of the estimation measurements. 

S – Sizable – it is about the proper scalability of the requirements, appropriate for the implementation phase. Requirements should be defined at a similar scale of implementation time or implementation effort by the deployment team. In more agile approaches this dimension is being referred to as “Small”, which means it should fit in a unit of iterative implementation, such as in sprint, for example. Awareness of the scale of the requirements allows the requirements to be properly defined, and facilitates the future activities during the deployment of the product, the product version planning phase or resource allocation, and testing. 

T – Testable – The last dimension of a requirement is its testability, meaning that the requirement has clear criteria to determine if the given requirement has been actually deployed. 

If the requirements meet the INVEST criteria, we can assume that the requirements have been correctly defined at this stage of the process. This does not mean that the work on the requirements is finished, especially when we are managing the project using agile methodologies. Nevertheless, it means that the requirement has been understood, properly described, it is sufficiently large, and the value and workload needed for implementation is known. 

Summary 

Agile approach is a key for gathering requirements regardless the whole project is leading according to traditional way, cascade way or in agile framework. Defining requirements we are moving from some kind of chaos or information entropy to the structured order. In order to do it correctly and omit many traps is necessary to do it in interactive way. Experience from agile frameworks are priceless for gathering requirement process. 

However, the agile approach help to start working on requirements in proper way very important aspect is to have good criteria to know when the work should be stopped. INVEST method is very helpful for this purpose. This heuristic support last step in the process of definition and gathering requirement definition and lead us to the list of well-defined list what should be ensure in the our system.