A list of clear requirements is what the development teams need to create the right product. Software requirements translate the expectations and needs of the users to functionalities and features that can be implemented. They can be obvious even from the beginning of a project, but sometimes they are hidden, implied and can even occur as unexpected guests in the middle of the development night. This meant that we needed to find a way to adapt to change efficiently: i.e. with the minimum loss in development effort and time.
However the previously widely adopted Waterfall paradigm, with its linear approach and long specification documents that bind the project to a static trail from its beginning, was not the best fit to this more user-centered and dynamic mentality.
A brief history of Agile
Conceived by seventeen people from the world of software development, somewhere in the Wasatch mountains of Utah back in 2001, the Manifesto of Agile Software Development was created. Its values were meant to become a massive hit in the software world. Customer centricity, reflection and adaptation instead of taking documentation as a gospel, short delivery cycles, autonomy to each developer and less centralized management, regular communication and face-to-face meetings, the bridging of business and development teams. These are some of the twelve principles that incorporate the values of the Agile Manifesto and make it ideal for projects like DataVaults, were adaptiveness, quick response to change and continuous development and improvement are in its core.
How to develop Agile?
Now that we got a glimpse of the background theory, we can move on with the application of the Agile mentality in the software development process.
When a project is developed in an agile manner, it is truncated into smaller increments, that minimize the overall risk and allow the product to adapt to changes quickly. Sprints are iterative short time frames, each involving a cross-functional team working in all activities necessary to deliver the final output for the specific time frame. Thus, once requirements are agreed at the beginning of such a time frame and an objective and target are set, all involved team members take part in planning discussions, in the analysis and design of the solution, in the coding, testing and acceptance actions to achieve the final output.
In general, the workflow of each iteration comprises of the following steps:
- Plan: The features of the next product increment are defined and clearly specified. Features are described as User Stories. To prepare the acceptance of a User Story by the Product Owner (see below), acceptance criteria are defined. Only if criteria are fulfilled, the user story will be accepted by the Product Owner.
- Design: Prior to commencing the development process, the system architecture is designed or updated by the system architects and developers.
- Build: The software is developed, always considering the predefined test criteria.
- Test: The acceptance criteria are translated into test cases. The test cases are applied to the product increment.
- Review: The development team presents the new features of the product increment to the Product Owner. The Product Owner checks if the requirements are fulfilled completely. In case of required changes new User Stories are defined.
Ok! But where do software requirements fit?
The answer is: in the Plan and Design steps! The user stories agreed in the first step of each iteration are the basis for the extraction of the functional and non-functional requirements that will be developed.
In order to begin however, the team needs a vision; What is the great picture of this product? What should it bring as added value to the users? A initial set of user stories and respective requirements that convey the findings from the landscape analysis and initial user research is required to kick start the design and development process. However these requirements are not considered final; on the contrary they are revisited regularly in order to end up with the really Most Valuable Product.
The DataVaults requirements engineering process
In DataVaults, the software requirements engineering process was initiated from the beginning of the project, with the identification of the DataVaults Data Value Chain and the features of the DataVaults Most Valuable Product. Combining the business user stories collected from the Demonstrators, the features of the MVP and the identified actors, we ended up with one card of User Stories for each component. These User Stories are then used as the ground to extract the system requirements.
User Stories
As DataVaults is a complex platform comprising various components that exchange data but have a certain level of autonomy when it comes to the offered services, it was meaningful to structure the User Stories around the foreseen components.
Each user story conveys not only what the user wants to do within DataVaults and why, but also: from which high level feature (Epic) does this user Story come from, which subcomponent is responsible to deliver the service, what are the acceptance criteria and finally, how crucial, valuable and complex is this story? This extra information is extremely useful at later stages, for the specification of the functionalities per component, testing and evaluation and effort/time planning.
Software Requirements
Once the user stories were collected, the next step was to extract requirements from them. The requirements were classified in the following two main categories; functional requirements (i.e. describing a functionality of the system), and non-functional requirements (i.e. describing an attribute of the system).
The functional requirements included except for their description, also the Epic under which they lay and the related User Stories to ensure completeness and traceability at a later stage, during development and revision.
Conclusions
This was the DataVaults agile-based software requirements engineering approach. If you want to see the complete User Stories and the requirements we ended up with after following this process, you can read the relevant deliverable D5.1 – DataVaults User Stories and NonFunctional Requirements.
