REQID

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.

Systems Engineering is Catching On

Mr. REQID — Sun, 07 Feb 2010 17:26:33 +0000

It seems to be a trend that customers are now asking for Systems Engineering Processes to be put in place on all types of contracts. It use to be just build type of contracts but now its showing up in other types of contracts for things like support programs. Systems Engineering process are a natural fit into these areas if you are flexable and can step outside of Mil-Std-1521. Those old processes are still a good standard for what they were writen for but they need some tayloring when it comes to commercial practices and support programs. With build programs you have a Physical product at the end of the process and with support programs there may be some physical elements the end product is a support process. So be creative in your design reviews and look for what is important for entry and exit criteria.

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.

Accept 360 First Glance

Mr. REQID — Sun, 03 Jan 2010 12:06:22 +0000

Complex, that was the first word that came to mind. While there are a lot of good features the 5 minute demos cater to management not the user. You can collect a lot of data in Accept that could be valuable if you are disciplined in the data entry.
My personal experience is that the more complex the tool the less likely that the data in it is going to be reliable. It would take a full time staff to just do data integrity.

I’m going to try and get an evaluation copy and give it a run thru.

Summary
Complex, but has lots of good features and analytical capability.

Requirement Tool Reviews

Mr. REQID — Sat, 02 Jan 2010 12:08:38 +0000

I have always been amazed at the blind dedication to some of the requirements tools that are on the market today. Some of these tools receive cult type status. In my consulting role i have use several of the most current tools and take a more pragmatic approach to tool selection. I am a master wood worker and as such have a wide range of tools. I choose the correct tool for the task and job i am doing at the time. I can’t build a book case with just a hammer.

So why is it that some people out there think that a single Requirements Management software tool that work for every program? Well i think its a two fold problem. First there is marketing hype, some of these tool companies have tremendous marketing and sales pitches. Second is a lack of experience in other environments. If you have only ever worked in software then you may be surprise when you come to the hardware side and find that we don’t manage requirements in the same way. You might even fight to try and do it the way it was done on the software side. The two are different is ways that may make it impractical to use the same requirements tool.
There are a lot of good tools out there and we should pick the best tool for the job at hand. There are some tools that are best for the software environment and some are better in a hardware environment. The challenge is when you have to merge the two. And there are some good tools out there for that as well.

This will be a series of reviews of the Current Requirements Management tools on the market from the big names to the upstarts. I will attempt to give a review that defines what the tools are best suited for.

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.