The world is going all tech and traditional approaches toward requirements collection and analysis no longer work as they did in the past. A growing number of organizations and software developers turn to Agile to fill the gap left by outdated methods such as the Waterfall approach. Actually, a recent survey shows that 63% of organizations worldwide already implement Agile and Scrum while 11% are planning to do so.
Adapting the structure of the traditional models for requirements analysis to Agile is simply a necessity in a fast-paced world where both technology and businesses need to be extremely flexible. System development and project management can no longer be successful if they rely solely on detailed preliminary analysis.
Source: Statista
The solution is to shift to a model where you continuously explore and adjust requirements with every iteration. Always having the big picture in mind and not working in silos in order to collect the right requirements at the right time is the key to success. We do this at eConnectivity by focusing on being up to date with industry standards and certify employees, most recently in two frameworks that align strategic business goals and system development. These frameworks are Scaled Agile Framework (SAFe) and International Requirements Engineering Board (IREB). But how does it really work?
Using Agile Principles in Requirements Analysis
By applying the core principles of Agile, you replace upfront, very detailed and non-negotiable specifications with a collaborative approach where all stakeholders collaborate iteratively to collect and analyze changeable requirements.
This collaborative practice eliminates the role-based silos and produces specifications that are more viable. Moreover, it creates a sense of ownership among all roles and builds a common understanding what features you need to build to add maximum value to the project.
Both the International Requirements Engineering Board and the Scaled Agile Framework ask for adapting to changes, stating that requirements analysis should be an iterative process, not an all-inclusive one.
Agile Model Driven System Development
Agile Model Driven Development (AMDD) consists of several best practices pertaining to business analysis and requirements analysis that equip you with a highly iterative, extremely collaborative and very flexible approach. These best practices will help you successfully apply the Agile method to your projects.
- Active stakeholder collaboration. Stakeholders collaborate to provide information and make decisions on time. All stakeholders actively participate in the development process.
- Prioritize requirements. Agile asks teams to implement requirements in priority order, in order to achieve highest return on investment (ROI).
- Do not over-analyze. Analyzing complex requirements that are not your current top priority should be made only when you expect real risks associated with them.
- Iteration modeling. Take some time to do some modeling at the start of each iteration to better plan for further iterations.
- Model storming. Model storm throughout an iteration to better understand the details behind a requirement.
Applying these best practices is essential as far as you have viable User Story, which represents requirements in a simple written narrative as opposed to a fixed and wide-ranging document.
User Stories Play Big Role in Agile Requirements Analysis
A User Story having good narrative is adding value for the end-user, partners and all stakeholders. The basic structure of a User Story would look like:
As a <user/system>, I want <what?> so that <why?>.
User stories make a Product Backlog, which is maintained and updated by the entire Agile team. Even though the Product Owner is responsible for and owns the backlog collaboration and transparency with the Agile team is key.
There are a few best practices to put User Stories work for you within the entire lifecycle of an Agile project.
- Use supporting materials. Not each User Story is detailed enough, so complement it with use cases, traditional requirements or decision tables.
- Write stories on functional level. Create specific User Stories that represent different functional areas of the product i.e. database, front-end, middleware or backend.
- Apply the INVEST principle. This approach asks for creating a User Story that is Independent, Negotiable, Valuable, Estimable, Small and Testable.
- Re-asses User Stories often. Organize daily or weekly workshops to brainstorm stories and classify them in accordance with their user themes. Then assign a priority of high, medium or low to each story and focus on improving high priority stories by applying the INVEST principle.
- Create prototypes from time to time. Building prototypes helps you test ideas and encourage discussions but only build prototypes you can really use within the project in some way.
Continuous improvement of your User Stories will help you in continuous delivery of an ever-enhancing product. It also helps you better understand new and changing requirements.
Concluding Words
The Agile approach does not require development and maintenance of comprehensive documentation when performing requirements analysis. Instead, make it lean and effective as well as adaptive to changes since the technology space is very fast-paced and any product should adapt to new requirements on the go.
Allowing change is a necessity for enterprises that do business in a rapidly changing marketplace where competition is fierce. And almost any market is such these days. Project teams should respond quickly to customers, product users and the market in order to develop viable products that reflect the business objectives of the owner but also please the end-user. Agile requirements analysis and project management gives you the tools to achieve both, and faster.
