There are a few software development models, and each has its pros and cons. Nevertheless, they all have one thing in common: whichever one you choose, it will influence your requirements management as well as other parts of the development. To begin with, requirements represent an early phase of the process, so it’d certainly affect the whole software, if for example sufficient time won’t be allocated in understanding operational concepts. Another tricky part is usually related to accomodating the requirements to project changes. How can you deal with these problems? Before you even start, you need to choose the right project management model for your software, and then adapt your requirements documentation strategy to your choice. In this article we present you 3 most common models, which involve entirely different approaches to requirements management.
Project management approaches
1. Waterfall approach
This traditional project management model is sometimes considered outdated, but it’s not exactly true. Smaller and relatively low-risk projects can comfortably use the waterfall method, as it relies on a constant progression through a series of stages, put in a linear way, in a defined period of time. Being logical and straighforward, thanks to its step-by-step nature, waterfall model has its supporters. Right from the start it initiates consultations with the stakeholders, including documenting, analyzing, validating and finally approving a complete collection of functional, non-functional, user interface, and business requirements, just as it is during early stages of a development process. After specific requirements are gathered together, the development team can move forward to the next phases of a typical cascade-like sequence, which usually includes about 5 steps:
The typical sequence of the Waterfall project management model
It’s best to use this model if:
- the objective is relatively static;
- the team operates under a focused need and the end-user environment is stable;
- risk factors like security, cost, and schedule are low;
- it’s unlikely that significant changes in requirements will be implemented after the project planning.
Structured organization and clarity of activities are the strong points of the waterfall aproach. In this traditional methodology, progress is easy to measure, as the general goals of the project are known in advance. However, there are also some issues, that can be met using waterfall model especially if the project requires more flexibility. The biggest disadvantage is the fact that even if one of the stages goes wrong, the development team may have to repeat all of the preceding phases until the error is corrected. That’s why your team members should always maintain a product requirements document which reflects the changes made throughout each part of the process. There’s one more thing that must be remembered if you’d like to decide on waterfall method for your project management: make sure to inform all stakeholders at the very beginning that changes applied to requirements later on in can be very costly.
2. Spiral approach
Sometimes you might start a project without a complete set of requirements at hand. In this case, the spiral model can help your team reduce the risk and deliver the requested software efficiently. This type of software development life cycle is pictured as a spiral with loops which represent the number of project management phases and can vary depending on the process. When requirements are known only partially, but stakeholders have a clear idea about the underlying operational needs and concepts, they can begin the project anyway – bearing in mind that the remaining requirements may evolve. Every cycle or iteration in the spiral model will follow the same process:
- defining objectives,
- considering alternatives,
- identifying constraints,
- producing a usable prototype.
Spiral development life cycle model, where loops in the spiral represent the number of phases.
It’s best to use this model if:
- the project model doesn’t include a complete set of requirements;
- some requirements are likely to radically change throughout the progression with the process;
- stakeholders’ or customers’ feedback is required to continue working on the next loop.
The spiral model is focused mainly on risk management, so in order to prevent extra costs and additional time loss, it bases on a progressive building of more complete versions of the software, thus upgrading the circle outwards. The idea is that the development team collects and documents requirements at the start of the project, but keeps on updating them after each cycle comes to a close. As each period finishes, stakeholders gather and analyze risks to come up with strategies for risk reduction used at the following level. On the other hand, customers may evaluate the product and suggest modifications that could be taken into account for the next loop. When the stakeholders confirm that the prototype satisfies the basic requirements and is operational, the project may be considered ready to release.
3. Agile approach
The Agile project management model takes an entirely different perspective on formal requirements documentation. Agile requirements are frequently expressed, in short, non-technical statements. As per the Agile Manifesto, the methodology as such relies on working with the comprehensive messages. Organizations use the Agile approach to develop a system over the course of successive iterations. That speeds up the whole development process and makes it possible to execute requirements simultaneously. In order to keep track of the whole process and avoid going back and forth, it’s necessary for the project team members to document all the requirements progress and changes made during the execution.
Agile documentation needs to meet the following criteria:
- information must be specific and to the point;
- valuable and required by the team;
- prepared right on time.
Sprints in Agile project management model
It’s best to use this model:
- for developing the software projects under high risk;
- when user environments are dynamic and prone to change;
- when the significant changes are expected to occur in succeeding stages.
Given these points, in Agile model requirements focus on the smaller cycles that are part of Agile projects. Requirements management usually includes significant collaboration with customers from end to end. With this in mind, team members responsible for documentation need to analyze the requirements as they evolve, make sure that the new or modified ones don’t violate regulations, calculate metrics, write functional specifications and finally: take care about the progress reports.
Requirements documentation in Jira
Not everyone knows that aside from being general project management and bug tracking tool, Jira can also be used for functional requirements management. Being fully extendable with integrated apps, Jira may help you execute the full software development life cycle inside a single tool. When dealing with describing the details of product requirements documentation, Confluence is the best way to go. Thanks to that extension, you can create issues arising from requirements pages, which can be linked directly to the features and testing objects. It will let your team members view the requirements content with related Jira issues. Developers can edit requirements and still be sure all stakeholders are up to date.
Moreover, there are tools designed especially for testing in Jira that are a great solution for standalone requirements organization as well. Regardless which project management model you choose for your software, preparing requirements is unavoidable, so it’s definitely worth a while to find a tool, that can help with that phase. One of them is our latest release: Requirements and Test Management for Jira (RTM). In RTM, it’s possible to structure and group requirements into transparent folders and subfolders, making them perfectly clear notonly for all team members involved in a project, but also for the stakeholders. With such a view changes are easy to implement, and you have a great choice of ways to structure your software requirements. With a good preparation at the beginning, the risk of making mistakes later on is much less probable.
No matter which project management approach you choose, you can structure your requirements in RTM
Requirements management can take on different shapes depending on your software development model. They can be set up at the very beginning or regularly updated with the evolution of the project. No matter which model you see fit, make sure that you won’t underestimate requirements elicitation and documentation stages, which are very important and strongly affects the final result. If you decide on using Jira for your requirements management, you will provide your team with a well-known, integrated environment, which helps to keep all the essential information in one place. Thanks to that, everyone involved in the process stays up-to-date – and that’s crucial, especially if you’re dealing with the project where initial requirements are very likely to change.
Requirements gathering is one of the most important parts of development process, essential in every project development strategy. We also invite you to read other articles on our blog, concerning requirements organization and implementing Agile software development model in Jira:
Kasia Kornaga is an Atlassian Apps Content Specialist, responsible for writing about requirements and test management on the Deviniti blog. She tries to discover and understand the mysteries of software testing process in order to share the knowledge with the readers interested in the subject. As an SEO enthusiast, most of all she values helpful, unique content where users can find answers to their questions, so she probably knows what you will look for before you even start. When she’s not writing, you can find her at the theatre, at home with a book or passing on city streets on her bike.