How To Choose A Software Requirements Model

Do you find that you're always trying to use process flows on your projects, but they just don't seem to fit your needs?

Do you need to start modeling requirements, but can't quite decide what models to use?

There are quite a few requirements models out there to choose from, ranging from the mundane (process flow), to the amorphous (use case) to the exotic (fishbone diagram). Knowing which models may be most helpful to you can be a bit tricky, but the following tips can help!

Choosing the Right Software Requirements Model

If your application has:

• Lots of User Interaction - useful models can be Org Charts, Use Cases, System Context Diagrams
• A Complex UI - useful models can be Org Charts, Use Cases, Wireframes
• Lots of Involvement with Different Systems - useful models can be System Context Diagrams, Data Flow Diagrams
• Data Processing - useful models can be Entity Relationship Diagrams, Data Flow Diagrams, System Context Diagrams

And don't stop with these - there are many other models to explore! Take the plunge, and break away from process flows today!

Check out these detailed explanations.

• State Tables
• Decision Trees
• Click Action Response Tables
• Data Dictionaries
  

How to Prepare for Requirements Sessions with Your Users - Tip 1

This is the first part of a four part series on how to prepare for software requirement sessions to be most effective with your users' time (and yours!).

Can You Get All of Your Requirements In One Session?

There is general agreement in the software industry that talking to end users to gather requirements is critical to the success of the project. However, a common issue is that users are particularly busy. For example, if an organization decides to add features to a call center application, talking to the call center representatives is critical, but it’s also costly to pull them away from taking calls. In addition, requirements analysts are extremely busy and may have to limit how much time they spend with any one user.

A common issue in gathering requirements is leaving a stakeholder meeting where you missed major requirements because the “next question” to ask did not occur to you at the time. It is unreasonable to think that this will never happen. The reality of software requirements efforts is that they are iterative. In addition, there is quite a bit of critical analysis that must take place, and that analysis cannot always happen immediately in a meeting environment. Whatever the reason, there is certainly a need to get the most out of time spent with the users. So how do you best prepare for meetings with your end users?

Software Requirements Sessions Tip 1: Organize Your Time

Requirements analysts should realize that the software requirements life cycle can be time intensive - including time to analyze, edit, review, and update. The key is to maximize the value from everyone’s time.

Make sure that requirements sessions are well planned, inviting the minimal group of people necessary to get value out of the meeting. The burden of extra time spent should be on the requirements analyst, not the users who are being taken away from their primary jobs. Prepare an agenda and appropriate artifacts prior to the sessions in order to keep the meeting focused on making valuable progress.

In dealing with any super-users who are unable to commit much time, it is important to zero in on specifically what information they must provide. Then allow these users to suggest alternative users to meet with to provide additional information, ensuring them you will allow them to review what the alternative users provided.

Come back soon for part 2!

How do you prepare for a requirements session? I'd love to hear your answer in the comments.

Why Traceability (by itself) Is Worthless

Performing traceability of delivered functionality to requirements without tying them back to Business Objectives is in my opinion an exercise in futility. To anyone engaged in this exercise, I ask “So What?”

At first blush this might seem like an extreme position to take. The benefits of requirements traceability seem readily obvious whether or not they are tied back to Business Objectives. You can determine what requirements were implemented, when they were implemented, what still needs to be done and so on. All of these are good things in and of themselves.

Do You Need Business Objectives For Software Requirements Traceability?

By way of answer, imagine that you are writing requirements for an Experiment Management system. Consider the following scenario.

The first set deals with setting up the experiment. The other set deals with analyzing the results of the experiment.

One of them is responsible for the team that defines and sets up the experiments. The other manager leads the team that analyzes the results of the experiments.

Each set had a total of 10 requirements each. The users prioritized their requirements and each team came back with 4 “critical” and 6 “nice to have requirements”. Assume that all the “Critical” requirements are equally important and deliver approximately the same amount of functionality each to the final delivered product.

They satisfied all of the “nice to have” requirements of both sets. All 4 critical requirements of the experiment analysis requirements were satisfied, but only one of the critical requirements of the experiment set up requirements.

Business Objectives Are Your Yardstick For Success

Simple traceability that did not tie back to Business Objectives would show something along the following lines:

By any yardstick it looks like a spectacularly successful release.

But consider for a moment if the Business Objective for the release has been defined as “reduce the amount of time taken to perform experiment set up by 90% so that the company can increase the probability of successful new product creation by increasing the number of experiments that can be set up by our team of scientists.” The company came up with this objective because it is far easier for them to hire analysts than find skilled scientists who can dream up new experiments that will result in new products.

If we were to apply this knowledge to traceability and coverage of requirements, a very different picture of the success of the release emerges.

All else remaining the same, from a Business Objective stand point, we have about 25% coverage of what is really important to the company for this release. So, this was a pretty dismal release though the raw statistics that do not tie back to Business Objectives seem to indicate otherwise.

At the end of the day, companies build software that advance their prospects and help them achieve specific business goals. As requirements professionals, we need to tie back the outcomes to the Business Objectives. So, if we are not tracing requirements back to the Business Objectives, we are generating data that may or may not be useful or relevant in the grander scheme of things.

There is definitely some virtue in generating data for its own sake. This would be the case in doing all the hard work to trace requirements to specific functionality that has been delivered. But not taking the final step and tracing it back to Business Objectives misses the whole point of the exercise. We are guilty of generating data without giving it the proper context that Business Objectives provide.

So the next time, someone tells you they are tracing delivered functionality back to the requirements, ask them if they are tying them back to Business Objectives. If the answer is no, ask them “So What?” I would.

Controlling Changing Software Requirements

The CCB (Change Control Board). It is their responsibility to oversee and approve any proposed changes to your software project. They're officially in charge of moving the cheese around - or approving completely new cheese.

Once they get to work, your nice, safe plate of Pepper Jack could morph overnight into something rich and strange, like English Farm Cheese with Dried Currants.

Project changes happen, but they aren't always easy to deal with. And they don't just affect Development (Nacho Cheese Doritos(tm)) or QA (Swiss Cheese).

It's critical that CCBs recognize that scope changes also affect documented requirements and the people who manage those requirements.

Scope Changes Affect Software Requirements Tasks

Changes approved by the CCB may generate requirements-related tasks, such as:

• Identify all requirements impacted by the change (requirements traceability will make this much easier)
• Update impacted requirements documentation and related models
• Manage review and approval of changes to existing requirements
• Elicit additional requirements to supplement or replace existing requirements
• Communicate all changes to impacted parties

Keep Business Analysts in The Loop

All impacts of a requested change must be identified and agreed upon so that informed decisions regarding the request can be made.

Even seemingly small or simple requests can easily become big changes when all of the related activities are considered.

Be aware, actively participate in controlling change on your project, and when your CCB hands you a wedge of Vieux-Boulogne (the world's smelliest cheese), you won't even blink.

Signing Out from INCOSE 2008

Well, I hate to say it, but my week here at INCOSE 2008 has come to an end. And though I must say goodbye to my INCOSE friends, I'm not headed home quite yet - first I will enjoy a few days in Amsterdam, just up the road from Utrecht.


A few final comments from this side of the pond (some of these are purposefully non-INCOSE related to keep it interesting!):

• After hours of listening to talks about process, I have to say - systems engineering processes are heavy! There are images dancing in my head of things like a project plan circle diagram that even in a 3x3 foot printout, you have to squint to read the tasks. Or there are the matrices that don't even come close to fitting on a page, yet they try to squeeze them in for demonstration of a concept.
• I spoke with some systems engineers who, when I explained what Seilevel does, said things like "Really? Requirements as a job?" or "You have a business around that?" or "I never thought of them as a separate thing, they were just some other task on my project that maybe got done." or my favorite "Why are you at a systems engineering conference then?"
• It's a small world. In a city of more than a million, today I ran into a fellow INCOSE member from San Antonio, TX on my way back from the Rijksmuseum.
• Most all of the presenters like to use words on slides! Seriously, I almost think it must have been in the presentation requirements - "Must have wordy slides". Perhaps I can suggest Beyond Bullet Points.
• I enjoyed reconnecting with my friends from what I like to call "Seilevel Europe", the HOOD Group (and mind you, they would and should probably call us "HOOD Group USA"). We have very similar companies, with similar methodologies, in different parts of the world. If you haven't heard of them, I encourage you to take a look at their work.
• Sadly, Holland just lost in the quarter finals of the Euro 2008. I say sadly because I've actually become quite fond of watching the "Oranje" games (or maybe just the crowds hanging outside of bars).
• I once again was reminded that so many Americans have a tendancy to focus on just us. This is by no means a generalization though. I personally like to intermix with those from other countries, though I'm also quite guilty of speaking American and little else. Anyway, it was frustrating to listen to talks from Americans who would only quote American statistics, or American events, or American disasters. My European friends were quick to point it out for me "Oh another American talk!". Thankfully some of the talks were very different than that though, making me much more proud.
• We should do more peer reviews, but not for the obvious reasons. A systems engineering organization requires team members to be on peer review boards, not so much for improving the quality of the deliverables, but more importantly, to expose the engineers to more projects and ideas that they can then apply to their own projects. Brilliant, I say!
• The field of systems engineering has many many many outstanding success stories, ranging from the Airbus 380 to the ProRail system of the Netherlands. There are lots of great lessons to be learned here that can be applied to much simpler projects. But really, how cool would it be to build a network of thousands of kilometers of rail or to put a new airplane in the air?

Anyway, in a few days, I will return home with many fond memories of the Netherlands and INCOSE 2008.

INCOSE 2008 - Can You Build an Airplane with an Agile Approach?

With all of the buzz about Agile, I have to mention that here at INCOSE 2008, I did not hear a single mention of it (except when I asked about it directly!). Actually, that’s not true, at one point I was excited to see a speaker’s slides which referenced applying agile processes as a step in a project. Then he spoke to the slide and I started to suspect he meant agile in the pure definition of the word, to move quickly. At the end, someone asked him the specific question as to whether he meant the agile software methodology and he clarified that he did not. So I left the conference wondering - with all the discussions about processes at a conference like this, why are they not ever speaking about agile?

Airplanes Are Not Software Requirements

My first guess - this probably relates to some of the core differences between systems and software engineering. I am going to over simplify this and just say that it is about scale. Systems projects are just a superset of software and hardware projects, integrating and deploying some combination of these. The teams of people deploying systems projects are quite large. And many of the projects discussed here are for government or regulated systems where specification and traceability is necessary. I could see how subsets of systems projects could in fact be developed using agile (pure software components), but I’m not convinced that an entire end-to-end project can. To put this in context, imagine you are building an airplane - a very commonly referenced type of systems engineering projects. Can you see this working using agile?

All skeptism aside, I do think that iterative development most certainly could work well on systems projects, and most people here would not argue that. In fact, I would love it if we could find examples of agile working on systems projects, because the number one feeling I get at systems engineering conferences is a craving for lighter processes.

I decided to do a little research outside the conference walls, and low-and-behold, I found a great article on this exact topic – “Toward Agile Systems Engineering Processes” by Dr. Richard Turner of the Systems and Software Consortium. The article is very well laid out, and I highly recommend reading it. He defines what agile is and what he believes the issue why most systems engineering projects are not agile. For example, he suggests that executives and program managers tend to believe that the teams involved have perfect knowledge about systems we are building, so we can plan them out in advance and work to a perfect execution against a perfect schedule.

Agile Can Work With Complex Systems

He talks to how to the agile concepts can work in systems projects. Here are a few examples summarized from his article:

• Learning based: The traditional V-model implies a one-time trip through, implying one time to re-learn. However, perhaps the model can be re-interpreted to allow multiple iterations through it to fulfill this.
• Customer focus: Typically systems engineering processes do not support multiple interactions with the customer throughout the project (just up front to gather requirements). That said, he references a study indicating the known issues with that on systems projects. Therefore, perhaps processes should be adapted to allow for this, particularly allowing for them to help prioritize requirements throughout projects.
• Short iterations: Iterations are largely unheard of because the V-model is a one-time pass through the development lifecycle. That said, iterations of prototyping through testing could be done in systems engineering in many cases. The issue is in delivering something complete at the end of each iteration. He suggests that this is not as important to the customer in large deployments as is reducing risk, validating requirements, etc. This is a great point to rememember the airplane example! Could we have even a working part of an airplane after 2 weeks? What about even the software to run a subsystem on the aircraft?
• Team ownership: Systems engineering is very process driven, so this one is tricky. Dr. Turner puts the idea out that perhaps allowing the systems engineers to drive it instead of the process to drive them, while more uncomfortable for management, might produce more effective results.

So while he does give some suggestions to adapt systems engineering processes to be more agile, I don’t think this will qualify as purely agile. And frankly if it we tried it, I think I'd be fearful to be in the airplane! But to quote Dr. Turner directly “…other hand, agility is much more a state of mind or philosophical approach than a set of rules that have to be followed regardless of appropriateness.” Using that idea, combined with what I saw at INCOSE 2008, I can see some definite opportunities for improvements for the field systems engineering.