REQID » Requirements Management

What is a Baseline

Mr. REQID — Mon, 06 Dec 2010 12:30:49 +0000

When all of the Requirements have been reviewed by the stakeholders and approve a baseline set of requirements is established.
The baseline is the starting point for your planning of both time and cost. This is the starting point but as we know it will change. As we move forward with the project we will find things that we missed and needs may change. This is ok as long as you started with a good baseline. The baseline allows you to analyze the impact to your program for both cost and schedule to determine if a change is cost effective. Without the baseline as a starting point there is no way to determine what the impact will be.
The baseline forms the basis for all work performed on the project without limiting the possibility to explore arising opportunities.
Maintaining the approved baseline through all changes and amendments is generally the requirements manager responsibility. All to often I find that programs do not have a dedicated requirements manager and that It is left up to someone as a part time job.
Changes will come from stakeholder inputs and user priority changes. Users may think they know what they want but will spot deficiencies in Business Requirements and propose improvements based on new understanding of what they can do.
Maintaining a baseline requires that any proposed changes go through a formal change request process to insure that all stakeholders have reviewed them for impact on requirements baseline. This impact analysis review should identify any impact to , scope, schedule, cost, contract, and work in progress. The impact analysis may identify that further evaluation is required and a repetition of the Requirements Management Process.
Baselines are not static but are a changing thing, but they are a starting point to measure form. All races have a starting line and baselines are that for development projects.

Better Requirements thru Less Paper

Mr. REQID — Sun, 05 Dec 2010 11:20:53 +0000

As a Systems Engineer it is always a battle to get the design engineers to create requirements. They just want to get to the design part or yell to the heavens that its COTs and we don’t need Requirements. Either way when we do get to the requirements I find that a lot of people are more concerned about the document than they are about the requirements. We spend a huge amount of time and money formatting, reviewing, printing, signing, and delivering a document that is going to change.
Modern requirements tools give us the ability to share and track all changes with the stakeholders without ever having to print a document. Things like digital signatures also help in this paperless process.
Point is that we would end up with better products if we stopped putting so much effort into a paper document and used that effort to write better requirements.

Configuration of your Configuration

Mr. REQID — Sat, 10 Apr 2010 11:03:55 +0000

Maintaining configuration of your product is always a challenge but keeping configuration of your requirements management tool can be even tougher. You have heard me talk about attribute creep in the past but attribute continuity is just as important. Naming conventions and continuity across requirement sets is just as important.
It bothers me greatly to see attributes duplicated across requirement sets named differently. This makes it difficult to write reports and is confusing to those that follow in your path.
So apply the same rigger in your CM of your requirements management tool as you would in managing your requirements.

Check out PACE requirements management tool at Viewset.com

PACE Requirement Tool Update

Mr. REQID — Sat, 27 Mar 2010 10:42:27 +0000

ViewSet just released a Beta version of the PACE Baseline compare feature that i needed for one of my contracts. I got to say that the beta is great and i can’t wait to see how the final version looks.

The PACE Requirements Management tool is getting better with every release. Whats really great is that when they make updates you don’t have to completely relearn the tool.

Requirements Management Organization

Mr. REQID — Sat, 06 Mar 2010 12:49:28 +0000

What i see all to often is that requirements management is delegated down to the teams to manage at their level. While this seems the efficient way to do business it has major drawbacks.
With out a central governing body you end up with a lot of inconstant looking requirements. Some areas will look good and some will look very bad. Some will just not get done at all.
The major problem then becomes that when you have to go in front of your customer and do the review its all over the place. It appears that you don’t have your act together and you don’t.

Point is you need a central body or group to assist the teams and to be the gate keepers of the requirements. We have seen it over and over where root cause of program failure to meet cost and schedule is a poor set of requirements. Yet we keep running head first into the same wall over and over again.

Wake up people and make Requirements Management a key factor in your planing and organization.

Working Live at 32,000 Feet

Mr. REQID — Sun, 07 Feb 2010 16:15:24 +0000

With global teaming a more commen theme in todays work place the ability to work on the fly or flying in my case is even more important. Airlines are realizing this and now almost all aircraft are equiped with WiFi in flight.
This makes having a tool that will work across the internet a must. I’m flying along right now as i write this at 32,000 feet and working on my requirements live for tomorrows meetings. I have about 8 hours of flight time today and see no reason not to use it productivily.
With the PACE Requirements tool i able to work with my live dataset back at the home base with out worry that when i go to sync up later that i will find that someone else has made changes before me. PACE is a requirements tool that has come into the jet age.

New Generation of Requirement Tool Users

Mr. REQID — Sat, 30 Jan 2010 11:52:10 +0000

I came to a realization the other day that maybe i’m in the older generation now. I have been reviewing the new crop of requirements tools that are out on the market and i was thinking this one looks alot like Facebook.
The new generation of tool users are more technically inclined when it comes to electronic tools. I keep looking at the new tools and thinking i have to be an expert in the tool to make it work well and i would never get the middle aged engineers to work in this tool. Then i looked around me and noted that half of the people around me where under 28 years old. The new guy as we call him that sits next to me is about a 1 out of college and is pounding away in the new requirements tool that we are using. While it is an easy enter face its still new to some of the old guys and they are slow on the uptake. Not that they are slow but its a change to a Web Based product.
With that said the new tools are very much into collaboration and shared work environments. While this sounds good at first i wounder if we aren’t moving to the point that to many cooks spoil the pot. The new tools provide a large and impressive amount of functionality but at what cost. I don’t need a space ship to move my couch to the new house, unless its on the moon.
Maybe i’m just middle aged but i think that when it comes to Requirements Management you don’t need a spaceship to manage your requirements. What you need is Basic Solid functions.

Easy of entry

Traceability

History

Reporting

Accessibility

Don’t make it so complicated that you need a PHD to master the tool.
My two cent form a Middle Aged Requirements Guy

Requirements Management and Software

Mr. REQID — Tue, 12 Jan 2010 11:01:46 +0000

As i read through articles on the web you would think that the only type of requirements in the world where ‘software’ and the only method to manage them was agile. The other alarming thing is the attitude that if your not using agile then you just don’t understand. As you have heard me say about requirements tools “the right tool for the job” the same goes for requirements management methodology.
That would be my before i go to work having my first cup of coffee insite for the day.

Writing Good Requirements Part1

Mr. REQID — Thu, 31 Dec 2009 12:45:17 +0000

Why do we have such a hard time writing good requirements? There are a couple of reasons the simple answer is that no one ever showed us how to write good ones. Another is that we don’t think that they are important and so it we just write them to fill in need to have requirements.
For whatever reason that we write bad requirements I think the first place to start in correcting the issue is to have a good understanding of why we need requirements and how they help us. This understanding will give us greater insight to writing good requirements.
I have seen design engineers fight tooth and nail to avoid having to write a requirements specification for something they needed to build. Arguments ranged from it’s a simple thing to its commercial off the shelf to I know what the customer wants. And then I have seen that same engineer meticulously documenting what he wanted in the new custom house that he was building. He was making sure that there was no room for the builder to get it wrong.
You wouldn’t just tell a builder go build me a house without telling them any details would you. I’m sure you are going to tell them things like:
1. How many bedrooms
2. How many levels
3. Do you want a garage
4. How many bathrooms
5. Where you want it built
6. When you want it built
7. How much you have to spend
So why is it that we resist the writing of requirements so much when it comes to our own work products? We are engineers and we just want to build things not have to spend all of that time writing it down. It’s not glamorous the writing of requirements but it is a necessary task. The other thing I see is that most of the engineers that fight the writing requirements don’t understand the bigger picture of what happens to validate or close a contract by verifying those requirements. They have the throw it over the wall syndrome. I build it and then it’s someone else’s problem to sell it off to the customer.
So let’s start with what is a Requirement? A requirement is a need, and a well written requirement will convey that need in a clear, concise and verifiable way to the people that have to meet that need. So lets look at the Need for a minute. We have to ask ourselves is it a Need or a Want and there is a big difference between the two. A need is mandatory feature, capability or function that we must have. A want on the other hand is nice to have and may make the product more friendly or easier to use but if it was not there the product would still fulfill the Need. For example a car needs 4 wheels. The owner wants White Wall tires and chrome rims. Does this mean that we don’t include Wants as requirements? No it just means that we need to understand the difference and make sure that we communicate this difference to control cost and schedule.
Writing good requirements will make everything better in the end.

Required Attributes

Mr. REQID — Wed, 30 Dec 2009 18:49:47 +0000

So what is the mandatory set of attributes to manage a set of requirements? Here is the list that I use and then expand on based on the project and metrics needed.
Minimum Attributes
1. Requirement ID
2. Requirement Text
3. Verification Text
4. Verification Method
a. Test
b. Demonstration
c. Analysis
d. Inspection
e. Process Control
5. Status
a. Open
b. Closed
6. Allocation: could be more that 1 type of allocation
a. Product Teams
b. Hardware or Software
c. Subcontractors
This I think is the basic minimum set of attribute needed to track manage requirements.
Of course I make this statement know that I will get all kinds of grief over it but I learned a long time ago if I wanted people to give there opinion that I need to tell them what it was first. It always gets them going.