Non-functional requirements: Planning out how well your software will work

A couple of months ago I wrote a post called Using nonfunctional requirements to build better software. It’s basically a step-by-step guide for creating an easy, practical technique to use nonfunctional requirements on a real software project, treating them in a way that’s similar to how a lot of Agile teams treat user stories, scenarios and other functional requirements: by sticking them on index cards and using them to do some lightweight planning.

Since then, I’ve gotten a lot of questions about nonfunctional requirements (or, as some people call them, non functional requirements, behavioral requirements, quality attributes, and probably half a dozen other names). Based on the questions I’ve been getting, a lot of people really seem to want a solid overview of exactly what they are:

• What are nonfunctional requirements?
• What goes into a good nonfunctional requirement?
• Is there a nonfunctional requirements checklist that I can use?
• How do I write down a nonfunctional requirement? Is there a nonfunctional requirements template I can use?

Luckily, Jenny and I addressed exactly those questions in our first book, Applied Software Project Management, and I’ve gotten feedback over the years from people who read it (and other writing I’ve done about requirements), and tell me it helped them get a handle on the concepts behind nonfunctional requirements. So I’ll do a little requirements Q&A and address those questions one by one, drawing from the book where possible. And I’ve posted an O’Reilly Community blog post called Understanding nonfunctional requirements with some additional information, which should also help get to the bottom of the issue.

Q: What are non-functional requirements?

Non-functional requirements — or behavioral requirements, or quality attributes — describe how well a system performs its function. This is fundamentally different than the typical functional requirements that most of us are used to, which describe what that system does.

Here’s a quick example. Whenever I’m talking about requirements, I like to use a “search and replace” feature in a word processor or text editor as an example, because we’re all familiar with how it works. So while a functional requirement for “search and replace” might describe how the case-sensitive matching works: “If the original text was all uppercase, then the replacement text must be inserted in all uppercase.” A nonfunctional requirement, on the other hand, might describe the performance (“it must be able to replace 1000 search terms in a 3MB document in under 250ms on one of our standard test VMs running at 50% load”).

Q: What goes into a good nonfunctional requirement?

A good nonfunctional requirement is one that makes it clear to everyone on the project — including the user (or someone who really understands what the user needs) — exactly how the software has to perform. Remember, a good requirement (functional or nonfunctional) is about understanding and addressing the needs of a user.

Here’s what Jenny and I wrote about nonfunctional requirements in our first book:

Users have implicit expectations about how well the software will work. These characteristics include how easy the software is to use, how quickly it executes, how reliable it is, and how well it behaves when unexpected conditions arise. The nonfunctional requirements define these aspects about the system. — Applied Software Project Management, p113 (O’Reilly 2005)

It’s really easy for non functional requirements to be unclear or ambiguous. The best way to make sure a nonfunctional requirement is clear and easy to use is to quantify it. So instead of saying that a task must be done quickly, write down the maximum number of seconds it must take to perform a task. The maximum size of a database on disk, the number of hours per day a system must be available, and the number of concurrent users supported are examples of requirements that the software must implement but do not change its behavior.

Q: Is there a nonfunctional requirements checklist that I can use?

We put together a nonfunctional requirements checklist that I’ve used many times on real projects. It’s based on a list of nonfunctional requirements we included in Applied Software Project Management.

Here’s one thing to keep in mind about this (or any other) non functional requirements checklist: as you’re reading it, you’ll probably find yourself thinking, “Wait a minute, all my software needs to be flexible (or efficient, or robust, etc.).” Yes, that’s true, of course. But are there specific non-functional requirements that affect your project in particular, above and beyond what you do on every project? That’s what this checklist is for, and that’s what you should be thinking about when you write down nonfunctional requirements.

• Availability: Are their constraints on the system’s availability or uptime?
• Efficiency: Are there resources the system needs to be careful about monopolizing?
• Flexibility: Will the system need to be altered after deployment?
• Portability: How easy it is to move to another platform?
• Integrity: How sensitive is the project to data security, access, and privacy?
• Robustness: Do error conditions need to be handled gracefully?
• Scalability: Will the system need to handle a wide range of configuration sizes?
• Usability: Are there specific constraints on how the users will understand, learn and use the software?

If you’re interested in using this on a real project , you can read more about it in that O’Reilly Broadcast post about non-functional requirements: I post a relevant excerpt from Applied Software Project Management that goes into more detail about each of these.

Q: How do I write down a nonfunctional requirement? Is there a nonfunctional requirements template I can use?

Yes. We put together a software requirements specification template, and I’ve helped a lot of teams adopt it for their own projects over the years. When we put together our requirements templates, we put a lot of effort into streamlining them as much as possible. So this is a sort of “bare minimum” template for writing down use cases, functional requirements, and nonfunctional requirements.

Here’s an example of how we’d specify a functional requirement:

And that gets back to the blog post I mentioned earlier, Using nonfunctional requirements to build better software. If you’re working on a team that uses an agile process to build software, there’s a good chance that you already write down a lot of your requirements on index cards. In that post, I outline a method that I’ve had a lot of success with in my own projects.

I went into a lot more detail in that post, but here’s a quick recap. First, I write the requirement itself on the front of an index card:

and on the back I’ll write a specific test to make sure the requirement is implemented:

Then I use it for planning the project to make sure it actually gets included — you can see more about it in the post. As far as documenting nonfunctional requirements goes, that’s actually a really efficient way of doing it, and I’ve seen it work well on agile projects.

I hope that answers some of your questions about using nonfunctional requirements in software projects. Obviously, I’d be thrilled if you took a look at the requirements chapter in Applied Software Project Management — Jenny and I gave a lot of practical advice about how to use requirements on a software project. And I’ve got other requirements posts on Building Better Software as well. But if they don’t answer your questions, feel free to ask (or send them to us).

We got this e-mail a few days ago from one of our readers:

Hello,

I bought your book, “Applied Software Project Management.” It seems very good overall, but I can’t get past the fact that your book seems to imply that software requirements come after the project plan/WBS/scheduling. Am I missing something?

On page 40, the script for estimating states that the input is documentation that defines the scope of the work being performed. Does this include the SRS? If so, why is this not made more explicit in your book (since requirements plays such a big role)? If not, how can a good estimate and schedule be generator before the requirements analysis has been performed?

I don’t get a solid sense of the relative timing of the activities (especially the requirements activity). Can you comment on this?

Thanks!!

– Wayne M.

That’s an excellent question. I’ve got a straightforward answer, and I’ve got a more involved answer.

The straightforward answer is yes. If you’re using Wideband Delphi (or, really, almost any estimation practice) to come up with estimates that you’ll turn into a schedule, then you need to get a handle on exactly what you’re estimating. So yes, when we say in our book that the input to the process is the “Vision and Scope document, or other documentation that defines the scope of the work product being estimated,” the “other documentation” we’re referring to definitely includes any software requirements you have. (For any readers who haven’t read our book, you can download a PDF of the estimation chapter that this reader’s referring to.)

Let me be clear about something here. You’re absolutely right that requirements analysis leads to more accurate schedules. If you’re lucky enough to have a really detailed specification at the beginning of the project that describes, in detail, all of the software that you’re going to build, then that will give you a much more accurate schedule than if you had a three-page Vision and Scope document that simply lets you know who the users and stakeholders are, explains their needs, and gives you the broad strokes about what features the team will build to meet those needs.

But when’s the last time you actually had the luxury of a complete specification before you had to deliver a schedule? And I’m stressing the word “complete” for a reason: it’s very rare that you’re done with the requirements before you’ve started building the software. So rare, in fact, that neither Jenny nor I have ever seen it in our entire careers, and I suspect very few (if any) of our readers have, either.

A good Agile developer might point out that this is the reasoning behind one of the core Agile principles: “Welcome changing requirements, even late in development.” And, in fact, that’s exactly why we dedicated so much of the chapter on software requirements in Applied Software Project Management to change control, because it’s important to not only accept that change happens, but to recognize it as a good thing. It’s better to change course partway through the project rather than to trundle on to an end goal that you know won’t actually meet your users’ needs or make your customers happy.

So with that in mind, go back to the process you mentioned. Specifically, take a look at the end of the script, because this is where it ties directly into the question you asked:

There’s an important idea there in those first six words: the project plan has been updated. That means that any time your world changes, you need to go back and update the scope, the WBS, the schedule, all the actual stuff you plan to deliverable (which might be written down in a statement of work), the list of people doing the work, a risk plan (if you built one)… all the stuff you used to plan your project.

…because there’s no single one Best Way™ to build software

And that’s why we didn’t give an explicit order to the activities. Sometimes you’ll end up planning out your project and building a schedule before you do requirements analysis; sometimes you’ll build a schedule after. Our goal was to help you do it well in either case. And by not forcing our readers into a single process or methodology, we don’t have to pretend to know all the answers… because, as far as I know, there is no single one Best Way™ to build software.  That’s the main idea, by the way, behind our “diagnose and fix” approach to improving the way you build software. Trying to overhaul your whole software process by doing a major process improvement effort is hard; adopting specific practices that make incremental improvements to the areas that hurt the most is much easier and a lot less risky.

This may sound like we’re calling for a lot of documentation, but it doesn’t have to be like that. Obviously, if you’re working on a team with dozens or even hundreds of people (like the teams Jenny often leads), this can be a pretty big task. But if you’ve got a small team working on a project that will take a few weeks to do, then this may just amount to rearranging your task board, updating your user story cards, updating a couple of Wiki pages, and having a quick stand-up meeting to make sure everyone’s in sync. That’s why people often talk about how running a really big team is like steering an aircraft carrier, because changing course requires miles of water, while running a small team is a lot more like piloting a speedboat that can change course really quickly.

So that’s the straightforward answer. But I think it’s worth delving a little deeper and asking an important question: What’s the nature of a schedule? I know, that probably seems like an odd question, but it’s actually important to understand what schedules are and how they’re used. (Technically, it’s only important if you want your projects to run well.)

A naïve answer might be to simply defer to that old project management chestnut: “Plan the work and work the plan.” If you haven’t heard that saying, take a minute and do a Google search for it. It’s one of those sayings that people love to quote, and it pretty much summarizes how a lot of people use (abuse?) project schedules.

I don’t like that saying, and there’s a reason for that.  I mean, don’t get me wrong, here. “Working the plan” is fine if it that plan accounts for changes. That’s one thing I really like about the PMBOK® and PMP approach: a whole lot of project planning revolves around how to handle changes, and specifically about dealing with change control. Also, it’s a great idea to make sure that you include a reserve for your project, and you can use risk planning to try to get a handle on the unknown.

To be continued in “The perils of a schedule, part II“

I got a great question from a software developer who also happens to be a fellow CMU alum.

I have a question related to managing scope creep with respect to “on-going”/iterative development processes.

I’m currently managing a project where we’re redesigning my application’s primary workflow. Simply put, the app is currently designed to have users to signoff all items and we’re redesigning it to be exception-based (only require certain items to be signed off).

As we’ve progressed down the path of planned iterative development, a lot of good/new ideas for future enhancements/requirements spring up. I find myself regularly working with my users and “working group” to prioritize and analyze if any of these new ideas need to be considered to build sooner rather than later (and thus triggering plan adjustments or delays).

I often feel like I’ll end up delivering a product that does deliver the initial vision, but still doesn’t make my users happy, as they’ve already shifted their expectations to wanted the “next” thing (aka phase 2).

Do you have any other tips about how to manage this process?

I’ve used things like taking a timeline-style roadmap and adjusting it by overlaying the new requirements and shifting the timeline out. Do you have an recommendations of ways to present this type of information?

Curious your thoughts. Thanks.

— Seth L.

Iterative software development can be a really useful—and highly effective—tool for software development, but it’s also one of the most abused tools I’ve seen. Even as recently as a few days ago, someone in charge of a software team that’s critical to his comapny came to me with the (incorrect) assertion that iteration just means diving into a prototype without talking to anyone or doing any investigation. Iteration done well can lead to very high quality software. But as Seth saw, iteration done poorly can lead to scope creep and serious planning issues.

Making your users “happy” means managing their expectations. They need to see exactly what you’re working on, and what’s coming next. If all people see is deadlines and they don’t have a sense of what’s going on, then they naturally start looking to the next deadline, because that’s all they see. The more visibility you can give them into the way you build software, the more understanding they’ll have – that’s just human nature.

There are a few things that work well for improving visibility into your project’s iterations. One of them is a task board, which typically involves sticking index cards with your user stories or scenarios on a whiteboard or wall. This means that you actually need to have user stories or scenarios. Scope creep is often an indication of a requirements problem, and getting consensus on at least the scenario level about exactly what’s going into the iteration. Having the index cards arrayed on a task board, with each index card showing the status (“planned”, “in development”, “completed”, “out of scope”) gives a lot more visibility into exactly what you’re building and how you’re building it. In a lot of ways, this is a sort of iterative development project plan.

Another way to prevent iteration-related scope problems is committing to delivering releasable code at the end of each iteration. Test-driven development (or, at least, developing complete unit tests) and continuous integration are effective ways to help make that happen. If your stakeholders are comfortable that you’ll deliver high-quality code at each iteration, they’ll feel less pressure to get the new features in immediately, and will be more willing to wait until the next iteration.

If this sounds like something that might help you, I definitely recommend reading the interview Jenny and I did with Mike Cohn for Beautiful Teams, who knows more about agile and iterative planning than pretty much everyone . He has a lot to say about effective iteration planning. There are pictures of task boards he’s used in the past.

That gets me back to the basic idea—one which I give Mike a whole lot of credit for helping people understand—that iterative development, especially in an Agile project, works best when we take the time to plan each iteration. It still faces the same problems: requirements need to be discovered, scope needs to be controlled, and progress needs to be communicated to everyone who cares about it… especially to anyone who can potentially make the developers’ lives more difficult. That’s why the most successful Agile development projects collect requirements and document them using user stories (or other techniques for writing down what the software needs to do). They plan their progress using task boards, forecast them using calculations and charts like project velocity and burn down rates, and constantly keep any business owners and other stakeholders up to date on their progress.

It’s a great way to develop software, and it’s been really effective for a lot of teams. And I think it shows that iterative development does not necessarily mean unplanned development.

When I sent this to the developer who sent me the question, he had an interesting follow-up, which I thought deserved a response:

So I’ve been digesting this a bit and I am curious to get your thoughts about adapting project management fundamentals into the often fluid process of app management. I manage a few virtual projects within my company and at times have struggled to keep things focused as business demands and/or interests shift over time. Similarly, the “iterative” approach has helped to clarify requirements while building out new flows/apps, but as you pointed out can be very tricky to get “right”.

It’s funny how often I hear people say, “Well, this project management stuff works in theory, but my project is fluid” (or “changing,” or “under too much pressure from the business,” or “critical,” etc.). It turns out that pretty much every project is challenging, and project management is set up specifically to deal with that kind of challenging project.

Here are two thoughts I had relating to this idea.

First, the iterative development model works very well, as long as you’re committed to delivering a high-quality product at the end of each iteration. Whether or not you develop using an iterative approach, you need to manage change: prevent unnecessary changes, and make sure you understand the impact of any change that you make. It also means that you need some sort of scope baseline, so that you know what is and is not a change. It’s faster and easier to update software on paper, before it’s written into code, so the more changes you can move to the “write it down and review it” phase of your project, the better.

And second, if your business is overly demanding, it often means that you could manage your stakeholders’ expectations better. Make sure you identify them – and write down their names and needs! – from the very beginning of the project. Talk to them… a lot. Make sure they’re in the loop. If possible, see them so often that they’re sick of seeing you. If they’re always aware of what you’re doing, there won’t be nearly as many surprises. Also, the more your stakeholders understand the details of the work that you’re doing, the more slack they’ll cut you when they ask you for changes. Often, when someone puts a lot of pressure on you to do the impossible, it’s because they don’t realize that’s what they’re asking.

James Turner‘s weekly O’Reilly Week in Review podcast this week features an interview with Jenny and me about Beautiful Teams, and what goes into making a team work well.

I’ll transcribe a quick excerpt from the interview – we’re talking about our interview in the book with NASA manager and team leader Peter Glück:

Jenny: You hear all your life about what it’s like to work at NASA. There were so many times we’d want to put in place a practice, and you’d hear, “Well, this isn’t NASA”. So to hear about how NASA actually did stuff was really exciting. It was such a revelation that they pretty much do stuff like everybody else, you know?

Andrew: I kind of had a feeling of, “They put their pants on one leg at a time, just like everyone else.” They build the same way, they test the same way, it’s just that they put a whole lot more time, money and effort into testing. And there are some things they can’t to. We talked about continuous integration. I asked him, “Do you do continuous integration?” Well, no, they don’t do continuous integration, because that involves integrating with a hardware platform that they have to take into a clean room. If your inegration process involves a clean room, it probably can’t be automated.

If you want a little background about what goes into building an O’Reilly book, working with the folks there, and some of the thought process behind Beautiful Teams, definitely have a listen. You can hear the whole interview here!

Jenny and I have been thinking a lot about teams lately. Working on Beautiful Teams really focused us on teamwork: what makes teams gel, what causes them to run into trouble, and what you can do to them. So when I got this question recently, it was really timely:

I’ve been working on bringing more of a teamwork feel to our projects for 2 years.  It has proven to be a non-trivial task. Any advice?

Now, just so we’re clear here, I know this guy pretty well. He’s a very good manager, and he runs a software development group with some of the smartest people I’ve met professionally.  They’re definitely a functioning group: they’ve been building software for years, and that software is used in production in critical applications at his company. By many accounts, his group is successful.

But when I took a closer look at how that particular team works day-to-day – and this should seem very familiar to a lot of developers – I definitely saw what he meant about it being a non-trivial task. There’s definitely a lack of a teamwork feel on the various projects his team works on. Everyone is really good at carving out his or her own piece of work, and is able to work on that piece independently. But even when multiple people would work on a single release of the same piece of software, they’d work independently of each other, not really talking amongst themselves. Don’t get me wrong – they definitely get their jobs done. But they’re working on individual tasks, not team projects. And even when those tasks add up to projects, it just feels like loosely connected tasks to the people working on them.

So what’s the harm in that, if they’re getting the work done? Well, for one, having a group of people working like that doesn’t exactly encourage innovation. There are some genuinely brilliant people on that team, and they do reasonably good work, but I would honestly expect more innovative work from this particular group of people. And I believe that having more of a “teamwork feel” would encourage more innovative work.

What’s more, I got the feeling that this particular team still runs into a lot of the same problems that many other, less talented teams run into, and I think those problems could be improved through better teamwork. They have some serious change management issues, where they often have to rework their code because it doesn’t quite meet the needs of the projects’ users. They have a few code quality problems – they’re trying to address them with better code reviews, which they’re having trouble getting off the ground. And they have an overall client relationship problem, where the people they build software for often feel like they’re somewhat disconnected, like they can’t quite the software that really meets their needs. Again, these are highly talented, very smart developers, with a manager who’s on the ball – and they’re still getting stuck on the same problems that hit everyone else.

Now, I don’t want to make the situation sound worse than it is. The manager has made some very good progress in getting the individuals working in a more team-like way. One thing he did that I really like (and I think it worked really well) was to really encourage everyone to write things down in the Wiki. And this wasn’t just a general edict (“Each person must add X wiki pages, or else!”). It was actual encouragement and support, treating documentation like it was a real and highly appreciated part of peoples’ jobs. Like a lot of new tools, there was a slow start to it, but once a few people dove in and started to embrace it, it started to really take off. And a funny thing happened: as people started sharing information with each other, they started to learn more about each others’ work, and some of them started to get that “teamwork feel” that they were looking for.

So what’s going on with this person’s group? And, more importantly, what can he do to help improve the “teamwork feel” for everyone?

Whenever I’m trying to help a group of effective but disconnected developers become a team, I like to start with this great analogy from Watts Humphrey:

There are different kinds of teams. In sports, for example, a basketball team’s positions are dynamic while baseball team members have more static roles. However, in both cases the members must all work together cooperatively. Conversely, wrestling and track teams are composed of individual competitors who do not dynamically interact, although the members support each other socially and emotionally.

In engineering, development teams often behave much like baseball or basketball teams. Even though they may have multiple specialties, all the members work toward a single objective. However, on systems maintenance and enhancement teams, the engineers often work relatively independently, much like wrestling and track teams.

A team is more than just a group of people who happen to work together. Teamwork takes practice and it involves special skills. Teams require common processes; they need agreed-upon goals; and they need effective guidance and leadership.

When I reread that quote before pasting it in here, something in that last sentence stood out to me: they need agreed-upon goals. Now, I’ve been referencing that quote for almost a decade. But it’s really interesting to me that I always overlooked that last bit. But working on Beautiful Teams really taught me the value of agreed-upon goals. It was pretty remarkable, actually: contributor after contributor brought up the idea that the people on a project all need to be aligned to the project’s goals, and to have a single, overarching vision that the team can rally around.

So if I had to give a single piece of advice to this manager, it would be this: try to find ways to give everyone a good sense of their goals. Two different Beautiful Teams contributors – Mike Cohn and Steve McConnell – talked about helping the team see an “elevating” goal. I really like how Steve put it:

First, the team leader needs to establish an elevating vision or goal, and I think that this is truly a leadership function, not just management. It goes beyond the management function. An awful lot of thought should go in on the part of the team leaders into what is the team’s goal and what is it about it that is not just trying to trick the team into thinking they have a goal that’s elevating or inspiring, but to come up with one that truly is.

A classic example is if you’re out digging ditches, that’s not very elevating or inspiring. But if you’re digging ditches to protect your town that’s about to be attacked by an enemy, well, that’s more inspiring, even though it’s the same activity. And so the leader’s job, really, is to try to determine or frame the activity in such a way that people can understand what the value is.

Now, that’s not an easy thing to do. But Jenny and I heard this message (or one similar to it) from so many of our Beautiful Teams contributors – Keoki Andrus, Neil Siegel and Mark Healey all come to mind, although other people talked about it too – that it actually changed the way I think about how teams work. In the past, I always looked at defining a project’s vision and scope as a straightforward tool for setting the top-level scope of the project and preventing changes. One thing I learned was that I wasn’t giving “vision” part of it nearly enough respect. Talking openly and often about that vision – and coming back to it when you do things like discuss project assumptions, come up with scenarios (or user stories, or use cases… however you figure out how your users will use the software) and plan out the work the team’s going to do – is the first step in really getting your team to have that “teamwork feel.”

Dear Jenny and Andrew,

I’ve been told by a couple of people “business analyst” positions were safe locally in the near future. I found “Applied Software Project Management ” on the internet. I’m currently trying to improve some of my skills, in an effort to re-enter the local job market. I’ve been a developer, programmer, analyst for over twenty years. I love building new software. I know you have a number of books that would be helpful. I’m also reading some of the “Head First” books. Is “Applied Software Project Management” the best place to start to build these skills?

Thank you in advance for your time,

Eric D.
Clemmons, NC USA

Now, this is an especially good question because it lets us plug our first book, Applied Software Project Management. More importantly, it’s a topic that’s near and dear to my heart, since I spent a few years managing a really incredible team of business analysts a while back. I learned an enormous amount from them, and I feel lucky that I can share a little of that with you, too.

It was near the tail end of the Silicon Alley dot-com days, although I was working at a decidedly non-dot-com company. At the time, I’d already been managing a team of software engineers — developers, architects and the like — for a few years at a New York-based financial software company. I felt a lot like Miles Silverburg on Murphy Brown: a relatively fresh-faced manager with a team of seriously seasoned and talented people who, to be honest, knew a lot more about the job than I did. Luckily, I’m a quick study, and I had some really great people to learn from.

First and foremost, I learned a lot more about what makes a good business analyst. Very few people start out as a business analyst — they usually move into the field from another area. Some of my team members started off as software engineers, others started off on the business side. What they all had in common was a deep understanding of users and how to make sure their needs were met. Throw in a healthy dose of project management knowledge, add a pinch of quality engineering, and top it off with a solid background in software requirements engineering tools and techniques, and you end up with a well-rounded, highly effective business analyst.

So that’s a tall order — and I should know, since I had to hire a whole team of people who fit that bill. I’ve gotten a lot of skepticism over the years from people who don’t believe that you really need someone who has such a broad background. And I’m sure that there are plenty of people with the title “business analyst” who can barely do their jobs… because there are people with every title in every industry who can barely do their jobs. But why does it take so much to be a good business analyst?

Consider what the real job of a business analyst is in a software project. She’s got to talk to users and figure out what their needs are. That’s a tough job, because users have a tricky habit of asking for things that don’t necessarily fit their needs. Time and time again I saw the people on my team tease the real needs out of users who, to be honest, didn’t really understand what they wanted. And that’s a really tough job. It requires some very solid elicitation skills, and a good familiarity with software requirements engineering tools and practices (like this one, this one and this one). Because the other part of the business analyst’s job is taking those needs and turning them into a functional solution that can be implemented in software.

That’s one thing that Jenny and I spend a lot of time talking about in Applied Software Project Management. We go over exactly what it means to construct a functional specification, and how that’s different from designing software. Just as importantly — and this is where a good understanding of quality engineering comes in — you need to make sure the users actually understand that solution, which means holding lots of reviews.

Finally, a good business analyst needs to be able to work with the rest of the engineering team to make sure that those needs and requirements actually get built into software. And that’s where a good understanding of project management comes in. She’ll have to work with the team to make sure they understand everything that needs to be built, and she’ll usually play a big role in the estimation — which means she needs a good understanding of estimation practices [PDF].

So to answer Eric’s original question, where should someone start building skills to get a job as a business analyst? If you looked at any of those links, then it probably won’t surprise you that I’d recommend Applied Software Project Management to anyone who wants to get a head start as a business analyst. I also really like Karl Weigers’ book, Software Requirements (2nd Edition). That book was a huge help to me when I was first learning about requirements engineering. I also learned a lot from Software Requirements Engineering (2nd Edition), a compilation of classic IEEE papers edited by Richard Thayer and Merlin Dorfman — including the classic Jim Rumbaugh paper on use cases, which I consider one of the most important papers ever written about requirements engineering. The best book on use cases that I’ve found is Use Cases: Requirements in Context (2nd Edition) by Daryl Kulak and Eamonn Guiney. When I was hiring business analysts, I would definitely have been pleased with a candidate who was familiar with the concepts in these books.