Q&A

A Learning Agile question from a business analyst

~ Andrew Stellman ~ Leave a comment

business-analyst

Jenny and I love hearing from our readers, and we got this excellent question yesterday from a Learning Agile reader (which I’ve edited a bit for length):

I’m just starting to read Learning Agile however I can’t wait until I’m done to comment on what I have read so far. The first thing I’ve noticed is there is no mention of a dedicated person, like a BA, writing the requirements. One example has the lead developer and architect, team lead, and product owner writing the requirements. No wonder the project failed.

I have been a full time BA for the past 14 years and for 16 years prior to that I was a developer who also wrote the requirements for the systems I built. I’ve only worked on waterfall projects and many of them were successful because of the requirements I wrote. I think there is a place for Business Analysts on Agile projects.

I’m curious why, up to this point in the book, business analysis and business analysts have not been mentioned in writing requirements for waterfall or agile projects.

I want to share the response that I wrote to this reader, because I think it’s a great question, and it really speaks till the goals that Jenny and I had when we wrote Learning Agile.

So first of all, both Jenny and I have a lot of respect for — and experience with — requirements management and business analysis. I even spent several years in the early 2000’s managing a team of BAs (much of it on the 78th floor of the World Trade Center!). Welcoming changing requirements is a basic principle of agile, so clearly there’s an important place on an agile team for someone with your experience.

So why don’t we talk much about business analysis or requirements management in the first two chapters of the book?

Jenny and I had a lot of long discussions about exactly how to handle this particular issue when we were writing the book, in no small part because business analysis and requirements engineering are very important topics to us personally.

Our book is called “Learning Agile” because we concentrated on teaching agile, and we put a lot of work into coming up with an approach that will work for the largest audience that we could. Because while that topic is at the core of software engineering and is a critical pillar of agile, it’s also very complex and nuanced. Frankly, it’s not easy to teach, and we wanted to get it right and teach it well.

In the last chapter, (“Coaching”) we mention an old saying about teaching: “meet them where they are, not where you want them to be.” We’d love it if all of our readers came to our book with the same deep knowledge of and experience with business analysis that you have. But that’s just not where they are.

So here’s the problem we needed to solve: how do we teach, say, a hardcore developer about requirements management — understanding what users need (as opposed to what they say they need today), and building great software that really meets those needs — in a way that helps him or her to not just understand it, but also care about it and recognize that it’s critical the success of to his or her own projects?

And just as importantly, how do we teach such an important topic to readers who not only don’t understand requirements management at all, but actually have negative feelings towards requirements (which, if you search programmer forums, is not uncommon)?

Our answer was to introduce the whole topic of requirements management very deliberately, and very carefully. We lay down a foundation in the first few chapters, so that by the time we teach about requirements backlogs in chapter 4, user stories in chapter 5, and minimal marketable features in chapter 7, we’ve given that hardcore developer with a somewhat antagonistic attitude towards business analysis the framework to really accept it.

And hopefully we’ll have done the same for you with other topics that we teach, so that when we talk about decoupled architecture and emergent design in chapter 6, it will feel familiar and make sense to you — even if you haven’t written a lot of code! — because we laid the groundwork and didn’t just dive into advanced architecture and design from page 1.

I hope this helps to answer your question, and that you enjoy the rest of the book!

Nonfunctional Requirements Q&A

~ Andrew Stellman ~ 3 Comments

Non-functional requirements Q&A: We answer questions from readers about using nonfunctional requirements on a real software project, and how to use them on a real software project.

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:

Name Nonfunctional requirement #7: Performance constraints for search-and-replace
Summary The search-and-replace feature must perform a search quickly.
Rationale If a search is not fast enough, users will avoid using the software.
Requirements A case-insensitive search-and-replace performed on a 3MB document with twenty 30-character search terms to be replaced with a different 30-character search term must take under 500ms on one of our standard testing VMs at 50% CPU load.
References See use case #8: Search

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:

Nonfunctional requirement index card (front)

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

nf_index_card_back.jpg

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).

The perils of a schedule

~ Andrew Stellman ~ 1 Comment

The walls are closing in

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:

Exit Criteria The project plan has been updated to reflect the impact of the change, and work to implement the change has begun.

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“