How To Prioritize Your Software Requirements, Part 1

One would think that since requirements are the necessary and sufficient list of behaviors needed to meet the business goals, prioritization is a non-issue. Everything is necessary, so why prioritize? Prioritization becomes an issue in the following ways:

• The initial vision is too costly or time-consuming to implement, we must scale back.


• The development effort will be done iteratively, and we must prioritize for the iterations (roadmap).


• Unfortunately, prioritization is also occasionally a proxy for controlling scope; the initial list of requirements represents more than the necessary features, so must be prioritized.

When you do need to prioritize requirements, don’t bother trying to put them in order. In the end, it doesn’t matter if one requirement should be ranked a little higher or lower than another requirement. You just want to figure out what to build. If you absolutely need 5 requirements fulfilled, ordering them 1-5 really doesn’t have any benefit. Determining that the 5 are absolutely necessary does.

You should use priority categories instead of an ordered list. The classic “high, medium, low” is easy, but doesn’t really map well to the real world. “Medium” is often just code for “not in this release, but not a bad idea”.

More realistically, you can use MoSCoW ratings (must, should, could and won't have). You may need to further prioritize the “should” or "could" requirements as “high, medium, low” so the team knows what to work on first when the “musts” and "shoulds" are done (wishful thinking!). Remember - these categorizations must be based on the business objectives.

So, what do you do when there is disagreement about the prioritization? I’ll cover that in Part II.

How to Select Software Requirements Training (It's not just about the BABOK)

So it’s time for your organization to select requirements training for your business analysts, product managers, project managers, even developers. Here are some suggestions on what to look for!

The obvious things to look for:

• Course Agenda – make sure the agenda is published and the topics seem relevant to your group. For example, if you do not use RUP, do not select a RUP-based class. If your team is good at the basics, consider a more advanced class, for example focusing on elicitation.


• Training Costs – these are relatively consistent across courses, but typically you can expect to pay anywhere from 600-1500 per day per student.


• Time Commitment – make sure you sign up for a course you are willing to commit to. Typically industry courses are run in full or half day increments. Make sure your people know it’s a priority to attend once you’ve signed up. Also, I prefer courses that are done in smaller increments, for example a series of 4 classes at 2 hours each, because the students can take time to think about and practice the concepts between classes. This resembles the teaching method used in universities, but it is very hard to find in industry.

The less obvious but more important:

• An Engaging Experience – the materials used during course must be engaging, as to not bore the students to sleep. As a rule of thumb, most learning happens in practice not lecture, so look for a course that has at least 50% of the time doing practice exercises.


• Competent Instructors – be sure that the instructors will be interesting to listen to. This may be tough to evaluate, but you could try calling them ahead of time. In addition, they need to be credible. My personal favorite is to find instructors who are also practitioners, having actually done the thing they are teaching. They will use more real-life stories in their teaching, which help put the lecture in context.


• Your Expectations - Be realistic yourself about what you will get out of the training and what you won’t. Referring back to the Kirkpatrick model, most training only measures levels 1 and 2, satisfaction and immediate recall of the material respectively. If you are looking for level 3 and 4, behavior change and impact to the organization, then recognize that most training alone will not give you those, and certainly is not likely to measure that they did happen. Typically mentoring in addition to or instead of training will help you get to level 3 and 4 in the organization.

Sadly, I have seen disappointed students coming out of all kinds of training experiences, and typically it is because their expectations were wrong going in.

Mattress Software Requirements

My wife and I recently set up one of our spare bedrooms using a bed frame that had been handed down in my family. We didn't have a full size mattress to put in it, so I ended up shopping for a mattress last weekend. Mattress shopping was easy. Mattress buying - much more complicated, and an example of software gone wrong.

After having selected a mattress, we began the checkout process. The sales rep looks at me sheepishly and says "We got new software last month. You'd think that I wouldn't have to click the mouse a couple hundred times to sell you a mattress!"

Sure enough, the sales process was rough. It needed my personal information in 2 places. We couldn't check on delivery dates until we'd finalized more of the sale. The sales person was visibly frustrated just trying to navigate the software.

This is obviously a classic example of software being built without feedback from the users. Now granted, there are probably lots of features in the software that the business owners wanted - prompts to suggestive sell upgraded warrantees, financing offers, etc. What was missing was the critical usability review from the people who would have to use the software every day, all day.

The 6 Things That You Must Have In Your RMP (and not just to have something to sit on)

When I was a little girl, my teacher told our class that "Prior Planning Prevents Poor Performance". There are coarser versions of this bit of advice, but it is nevertheless true. SO, if you are starting a new requirements project, having a plan will help YOU to prevent poor performance, or at least to stave it off.

You will need a RMP. A Requirements Management Plan. Not a "rump" - try searching for THAT on the internet while looking for free stock photos for your blog post - the results can be quite shocking, and generally fall into three categories:

• beef rump roasts - yuck! I'm vegetarian


• canine rumps - generally cute


• human rumps - generally yucky

Nary a RMP in sight. But (no pun intended), I digress.

Top 6 RMP Chunks

If you're trying to create a RMP, you should include these 6 task categories, at a minimum:

• Project Setup. Set up some project kickoff meetings, take time to explain your approach to requirements gathering to your project team, get your software tools set up.


• Project Scope Definition. Elicit and document business objectives, create problem statements, identify risks.


• Information Gathering. Dig up any and all existing documentation and read it. Identify actors and the roles they play, and set up meetings with them. Identify systems affected by the project, what those systems do and how they interact with each other. Identify data elements, how they are managed, and who uses them.


• Requirements Documenting. You know how to do that! ;)


• Requirements Review. Identify your document approvers, set up and hold review meetings. Get the approvers to sign off!


• Baselining. Establish the change control processes that your team will use, and baseline your set of deliverables. You mustn't start changing things until you've got a baseline.

Once you've created your RMP, go publish it! Send it out to your project team. Give them updates when changes occur, and you'll keep the team on track and greatly increase the chance that your project will be successful.

Six Sure-Fire Ways to Make Scrum Fail

I joined a project which was trying to use Scrum.

After a quick read of Agile Software Development with SCRUM by Ken Schwaber and Mike Beedle, I was intrigued. What Schwaber and Beedle had to say passed the “gut check” and I wanted to see it in practice. Their basic arguments which warrant exploring are:

• Software development is unpredictable. You need a project management/process control system which adapts as you learn, and you should evaluate and apply what you are learning on a regular (monthly) basis.
• Developers must be held accountable for delivering what they promise. Developers can only be held accountable if they are empowered to solve problems.

I’d like to share our success story, but what I do have to share is lessons in how to make sure Scrum fails:

1. Interpret “Scrum” to mean there is absolutely no overall project planning or vision. After all, Scrum isn’t an empirical process control model; it’s a license to start development without an end goal in mind.
2. No software architecture! We’re agile; we don’t need no stinkin’ architecture!
3. That thing about removing impediments—it doesn’t apply if it means organizational change, it only applies to the project team. Empower development teams? Well, not if it’s hard.
4. Expect to get it exactly right in the first few sprints. If Scrum really worked, we’d get it right the first time, correct? A shift in team and organizational thinking shouldn’t take any effort.
5. The test team should refuse to play. Moving fast isn’t necessary, testing everything at the end of all the sprints is fine, correct?
6. Interpret the potential for refactoring code to mean that there is absolutely no reason to write good code to begin with, because you can always refactor it!

I joined the project at the beginning of its 3rd sprint, and Scrum was dropped in the 4th sprint. I still think Scrum has a lot of promise, and would like to give it a real try one day.

Related Reading:

Scrum Devleopment Process by Ken Schwaber.

7 Ways to Fail with Scrum by Jeff Sutherland

How to Prepare for Software Requirements Sessions with Your Users - Tip 4

Our final suggestion on this topic is to Sit With Your Users.

If your users are extremely busy, and the project involves changes to or replacement of an existing solution, then turn the challenge into an advantage. Sit beside the users while they perform their job tasks.

Typically this is a good way to elicit requirements because users cannot always articulate their needs if they are used to completing tasks without thinking about them. This technique will require follow-up meetings with the users after, but then those meetings can be prepared for as above, with intelligent questions based on the observations, thereby shortening the time that users are away from their work.

Let's recap, we've now offered the following suggestions to prepare for requirements sessions with users:

1. Organize Your Time
2. Prepare Your Requirements Models In Advance
3. Prepare Your Elicitation Questions in Advance
4. Sit With Your Users

There are many ways in which requirements analysts can intelligently prepare for requirements sessions with users. Typically a mix of the above suggestions will work well on any project. These tips will help the analyst and users get the most value out of the available time.

By the way, you can download all of these tips in a whitepaper that I've written. Enjoy!

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

We have now discussed the need to organize your time and prepare models in advance of the sessions.

Today we suggest you Prepare Your Elicitation Questions in Advance

One of the key steps to take prior to a stakeholder meeting is to prepare a list of questions to be asked during the meeting. These questions might be created based upon past experiences or recent meetings with the user. If the analysts know the users, the organization, or the types of issues they face, that knowledge should lead to obvious questions. If the analyst has met with the user already, new questions should be created based upon those original meetings, lessons learned and new issues identified. Also, if drafted models exist, those most certainly should prompt questions.

There are some stock questions that you can use as a guide to requirements gathering sessions. Keep in mind, though, each project will need its own unique questions, and some of these questions are likely not appropriate.

How to Identify Actors for Software Requirements

Here are some suggested questions to ask to identify the actors of the system. These questions are in a guide that we've design to keep on your desk. Download it here.

• Who uses the system?
• Who installs the system?
• Who trains people to use the system?
• Who fixes the system?
• Who starts up the system, who shuts it down?
• Who maintains the system?
• Who creates, updates, deletes information in the system?
• What other systems interface with the system?
• Who gets information from this system?
• Who provides information to the system?
• Does anything happen automatically at a predetermined time?

How to Identify Use Cases

The following suggested questions can be used to identify the list of use cases or system functionality.

• What functions will the actor want from the system?
• Does the system store information?
• Do the actors need to create, update, or delete information?
• Does the system need to notify an actor about changes in an internal state?
• Are there any external events the system must know about?
• What is the actor’s overall job?
• What problems has the actor had in the past?
• What steps are manual today?

How to Identify Alternative Courses

In order to identify alternative courses or exception paths, these questions should be asked at every step of a use case main course.

• Is there some other action that can be chosen?
• If X does not happen, then what should happen?
• What if the actor cancels an operation (e.g., closes a window)?
• What if the actor provides incomplete information?
• What might go wrong at this step?
• What if part of the system goes down or is unavailable?
• Are there any events (or interrupts) that might occur at any time during the use case?

Are you ready for the last part in our series? It's an oldie, but a goodie!

How to Prepare for Software Requirements Sessions with Your Users - Tip 2

Last time we talked about organizing your time.

Today's suggestion: Prepare Your Requirements Models In Advance

Prepare draft requirements models in advance of the meeting. The reality is that good requirements analysts do in fact know quite a bit about the business processes and requirements. There is a misconception that they should remain unbiased; however, these individuals become experts in the systems they are capturing requirements for and that expertise should be utilized to its full advantage.

As an example, if you are going to cover a topic with a user about how he or she does a task, then you can try to come up with the obvious use cases in advance. You can then take it one step further and actually try to write the header information and normal course for the use cases. Similarly, you may find it valuable to draft state diagrams, where you capture the states and transitions that are obvious and highlight the unknown ones for completion in the meeting. Virtually all requirements models can be pre-drafted if you know a little bit about the business.

In doing these models ahead of time, you will find yourself jotting down lots of questions in the margins, like "What really happens at this step?" or "Should they do X instead of Y?". Even if you throw away the draft model because it was all wrong (which rarely happens), there is still a value from the time investment because you came up with a list of detailed questions. Essentially this is a brainstorming tool for you.

Starting from a blank slate can seem like a daunting task, so once you have draft models, in the meetings with users, you can use these models to work from. Similarly to the authoring experience, reviewing the models will spur questions in the reader’s mind. Therefore they make an excellent tool with which to facilitate a user meeting.

See another great post on how to choose a requirements model.

Come back for part 3 next!

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.

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