Requirements Management

Learn How to Create SRS Documents in 10 Seconds

Hi, it’s Allison again. When most people think of three little letters that might save your life, SOS comes to mind. But for me, S-R-S is the ultimate lifesaver when it comes to project management. SRS stands for Software Requirements Specification, which is a document that fully describes the expected behavior of a software system.

Functional requirements are documented in an SRS, as are non-functional requirements such as performance goals and descriptions of quality attributes.

The SRS states the functions and capabilities that a software system needs to provide, as well as the constraints that it must respect. The SRS provides the basis for all subsequent project planning, design, coding, and testing. Virtually everyone involved in the project rely on the SRS. The development team, maintenance staff, testers, technical writers, support people, and the marketing department, This is why this document is so important.

There are many significant benefits to having a SRS document. For starters, the SRS improves communication between your team members by saving and displaying the product feature description in one central location that everybody can easily access. It also prevents confusion within your team by maintaining an up-to-date definition list of all the features included in the project. This way you ensure that everyone develops the same set of features, avoiding a situation in which there are several different versions of product documents out there. And because all that information is available in one document, the SRS makes it easy for new employees to quickly learn the details of the project.

Another benefit that comes from the development of the SRS document is that it ultimately saves you the effort and cost of late-stage re-design and re-testing. That is because putting the SRS together requires all stakeholders to agree on the requirements at the beginning of the project.

Given that estimating costs and developing a project schedule can be a challenge for any project manager, the SRS document provides a great deal of help in that area as well by acting as a basis for creating such estimates.

Other benefits of utilizing an SRS document include its ability to provide a basis for enhancement of the product at a later time. The SRS can also provide a baseline when it comes time to develop plans for validation and verification.

Furthermore, the Software Requirements Specification functions as a contract between the client and your company. Once the SRS is complete, you can simply send it to your clients, and it will act as an agreement of what should be developed.

Now I initially planned to give you a template of an SRS document that you can use to create your own. But then I thought, why do that, when you can just use Elementool’s Requirements Management to automatically create SRS documents, in seconds, right from your feature requirements list? Simply:
Go to the ‘View Requirements’ page.
Click on the Print Requirements button.
On the right side, select the features you wish to include in the SRS document.
Move them to the left side.
Click on the Print Document button.
And, voila, I have an SRS document ready in less than 10 seconds.

It couldn’t be easier!

Give Them What They Need

Carl is managing a major software project for his company.
The client calls Carl and talks about what needs to be done for the project in general.
As project manager, Carl brings his team together for a meeting and explains the project scope. Unfortunately, he forgets to bring up a few crucial details.

The team works hard on developing the project, based on the instructions they received from Carl. Because the project description that they were given was generalized and lacking in certain details, team members frequently find themselves filling in the gaps by making assumptions about what they think the client would like. Many of their assumptions are incorrect.

When the project is finally completed, Carl proudly shows the end product to the client. But the client can’t believe what he’s seeing – this product is not what he wanted at all!
The client is furious over the many months wasted and the large amount of money spent on developing a failed project. Carl is embarrassed by the unwanted result, and now he and his team must start the long process all over again.

Meanwhile at an office two floors below, Sarah is managing her own team as they begin work on an entirely different software project.

As project manager, Sarah makes a point of meeting with her client and asking the client to carefully explain what he would like to achieve with this project. They discuss each feature in great detail.
Sarah uses the Elementool Requirements Management tool to write the project specifications and capture the details of each feature. This easy-to-use tool helps her to quickly acquire and organize important information about the project.

Sarah then creates an SRS document using Elementool’s Requirements Management and presents it to the client for approval. The client later sends along his comments, and, once the missing details have been corrected, he approves the project plan.

Using the integration between Elementool’s Requirements Management, Time Tracking, and Issue Tracking, Sarah is able to create tasks for her team based on the project plan.

The team develops the project according to their project manager’s plan and the project is released on time with all the right features in place. The client is thrilled with the result, and everybody is very happy.

Learn Agile Development in 3 Simple Steps

I’m Allison and I’m going to teach you Scrum Agile Development in three simple steps.
This is a special video I created just for Elementool’s clients and the people on our mailing list.
So if you’re watching this, you are one of the special lucky people who, within a few minutes, will have a system that will help you to improve your development performance immediately.

Download Agile Flowchart

Why do we need Scrum in the first place?

In many cases when you develop a software project, you know how it starts but you cannot predict what will happen after a few weeks of development. As a result, it becomes difficult to keep track of the project progress. If you’ve ever felt that things get out of control, you know what I mean.

Delays cause the project to cost more, because you need to pay for additional development time. They also cause your clients to get upset and this is something we want to prevent.

Scrum enables you to keep everything visible. It allows the team to know exactly what’s going on and make adjustments to the project to keep it moving forward.
With Scrum you build pieces of the software. The client can experience each part and determine what to do next. This way you have control over the progress of the project and the power to prevent delays.

Let’s get started:

Step # 1 – Create a Backlog

The project backlog is a list of all the features that clients would like to have as part of the complete product. It includes the client’s dreams and wishes. But it doesn’t mean that everything will be developed, as we’ll see later. The Backlog is created by the Product Owner. The Product Owner represents the interest of the people who ordered the product – the clients.

Step #2 – Estimate and Prioritize

After completing the Backlog list the Product Owner estimates how long it would take to develop each item on the list. There are different ways to estimate and I’ll explain them in another clip. Next comes prioritization. The goal is to focus on what brings value to the business. The Product Owner sorts the backlog items by priority, from the most important at the top to the least important at the bottom, picks the features that should be included in the release and creates the Release Backlog.

Step # 3 – Sprint

Here is when most of the work is being done. Sprints are development units between 3 to 30 days. A project usually includes several sprints.

At the beginning of each sprint the team will have a Sprint Planning meeting. In this meeting the Product Owner and the team get together to decide what will be done in the new sprint. They select items of the highest priority from the Release Backlog. The Product Owner describes to the team what is desired and the team decides how much of what is desired they can complete in this sprint.

The Sprint Planning meeting has two parts:
The first part is spent with the Product Owner to decide which features to develop.
In the second part of the meeting the team plans out the sprint. The selected tasks are placed in the sprint backlog and assigned to the team members.

Everyday the team meets for a short 15 minute meeting called “Daily Scrum”. In this meeting each team member answers three questions:
• What have you done on this project since the last daily scrum meeting?
• What do you plan on doing on this project between now and the next scrum meeting?
• What stands in your way to meet your commitments to this sprint and this project?
The purpose of Daily Scrum is to synchronize the work of all team members and address any issues that might delay the work progress.

In every sprint the team must complete the work that was defined for this sprint. Bugs that are related to the features on the Sprint Backlog should also be fixed as part of the sprint.

At the end of each sprint, a Sprint Review meeting is held. In this meeting the team presents what was developed during the sprint to the Product owner and other Stakeholders. This meeting helps to decide what the team should do next. The clients can see the project progress and submit feedback. It prevents the risk of developing features that the client didn’t ask for. Also, in case of a delay in the development process, the sprint will not be completed on time and that will indicate to everyone that there is a problem and something needs to be done.

Repeat step 3 until all features on the Release Backlog are developed and the product is ready to be released.

That’s it. So easy. As you can see, Scrum is a simple and effective way to have control over your development process and make sure things go according to plan.

I created a flowchart for you of the three steps. You can download it using the link below.

In this clip we’re going to focus on one aspect of project management: Requirement Management.
We are going to reveal another secret related to the “rules of the game”, and why projects are delayed, exceed budget, and in many cased don’t come out as designed.

Research shows that 71% of software projects that fail, do so because of poor requirements management. This is the biggest reason for project failure.

The Standish CHAOS Report, which surveyed 9,236 IT projects, found that the top three causes of project failure were lack of user input, incomplete requirements or changing requirements.

Another secret we are to share with you today is: You cannot win a game without solid strategy.

Requirements management defines the project and provides a framework that enables to track and complete the project progress and objectives.
Like in a basketball game. First the team designs the game strategy. They do that before the game. Then they discuss and practice it and implemented in the game.

A product requirement is anything that is required to make a product complete and successful. There are high level requirements, which must be broken down into smaller individual items for each function, and then documented and tracked.

Requirements management is not just a process that you do at the beginning of the project. Just like in a ball game, the game strategy needs to be monitored and updated during the game. Requirements management is a process that gets the most focus at startup, but then monitored, and updated continually throughout the project lifecycle. Just like a coach will call a time out or talk to his players during half time to make sure that the strategy is still working and if it needed to be changed.

It is best to use software designed for requirements documentation to document the process. This will allow better product development and tracking once the requirements stage is completed and the development phase starts.
The software should track the list of requirements that will be the source of data for all other steps in the requirement phase.

It is common that teams treat anything that is not coding as a waste of time. Many companies are eager to start with the coding of the project as soon as possible, because it gives a feeling that they are working on the project and tend to neglect or don’t give enough attention to the requirements management process. It’s just like basket players that want to start dribbling and playing instead of sitting at the office and think about strategy. You can be an excellent dribbler, but you cannot win the game without strategy.

We are going to teach step by step how to plan your project strategy and create the requirements. We have developed a simple system that you can implement right way. In fact, this new system is so powerful that you will call us and ask us not to sell it to anyone else.