Your project management methodology vs. requirements documentation

Updated on July 11th, 2021, by Magdalena Korgul

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 the 3 most popular project management methodologies, which involve entirely different approaches to requirements management. 

What is a project management methodology?

A project management methodology can be adapted to several numbers of industries or types of projects. Knowledge of different types of these sets of guiding principles is crucial for implementing them accordingly to any project. It often happens that – even if we have plenty of project management methodologies to choose from – the best solution turns out to be a hybrid approach. But in order to apply it correctly, first, we have to get to know the basics.

That’s why we selected the 3 most frequently chosen project management approaches and point out where implementing them would be the most beneficial for your requirements documentation.

Project management approaches

1. Waterfall approach

This traditional project management methodology 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 straightforward, thanks to its step-by-step nature, the 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 a functional, non-functional, user interface, and business requirements, just as it is during the 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:

  • design
  • implementation
  • testing
  • deployment
  • maintenance
waterfall approach: 1. Analysis, 2 Design, 3. Implementation, 4. Testing, 5. Deployment, 6. Release & Maintenance

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 project management methodology. In this traditional approach, 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 the 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 that 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 a waterfall method for your project management: make sure to inform all stakeholders at the very beginning that changes applied to requirements, later on, 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 that 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 approach: Risk identification and resolving, Development and testing, Evaluation and planning, Determining objectives

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 project management method 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 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.
Sprint 1: plan, design, build, test, review, client feedback, no: next iteration/yes: release. Sprint 2: plan, design, build, test, review, client feedback, no: next iteration/yes

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 the Agile project management methodology requirements focus on the smaller cycles that are part of Agile projects. Requirements management process 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 of 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 of 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.

Requirements, Tree of folders on the left hand side. On the right hand side New Requirement Details: Type of Requirement: UI Requirement, Select older: App requirements, Assignee, CTA create button

No matter which project management approach you choose, you can structure your requirements in RTM

Keynotes

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 affect 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 a project where initial requirements are very likely to change.

Requirements gathering is one of the most important parts of the development process, essential in every project development strategy. If you’d like to learn more about requirements management in Jira Software, check out this video tutorial series on our YouTube.

Katarzyna Kornaga

Katarzyna is a Content Specialist, responsible for writing on the Deviniti blog. As an SEO enthusiast, most of all she values helpful, unique content where users can find answers to their questions. When not writing, you can find her at the theatre, at home with a good non-fiction book, or passing on city streets on her bike.

More from this author