The AppLife Update Blog

  • Functional Requirements Completeness vs. Scope Creep

    When discussing software requirements documentation, a very common question asked is "When is a software specification complete?"  This is a very subjective question, and answers are often as far apart as discussions comparing waterfall to agile software development methodologies.  I like to break the discussion into two parts.

    1. When is requirements elicitation complete?
    2. When is requirements elaboration complete?

    If you split the question and look at the issue in this way, you can at least get to a non-subjective half answer.  I know... what a terrible result.  But the truth is sometimes like that.  The answer to question 1 is still subjective, but at least we have succeeded in identifying a more specific point to discuss.  completeness The answer to question 2 is far less subjective.  In fact, removing arguments based on the quality of the elaboration work product, one could argue that answering question 2 is absolutely non-subjective.  Requirements elaboration completeness is identified when all elicited requirements are described sufficiently to transfer understanding of the requirement to the software documentation reader.  In other words, when each requirement is checked as complete by the software documentation author, and agreed as complete by stakeholder reviewers.

    The Requirements Elicitation Completeness Conundrum

    Question 1 is much harder to identify. The inability to identify the answer to this question, and the frustrations of teams that have tried, is a huge contributor to the industry-wide recognition of agile methodologies as a potential better way to work software projects.  Any attempt at identifying completeness can only take into account known issues. You simply don't know what you haven't yet discovered, and the best advice in assessing requirements completeness is to acknowledge this simple truth.  Don't get hung up on it.  Diligently attempt to elicit the known requirements, and plan to iterate early and often in order to catch the unknown requirements. 

    It can become very costly when we try to completely identify all requirements of a software project up front.  This cost is not just in the analysis time we spend chasing perfection, but also in all the requirements that are identified in our quest, but are not really requirements. These requirements turn into software features that are developed, but never used.

    Software teams should expend reasonable resources in identifying known requirements up front, elaborate those requirements to completeness, then recognize and embrace requirements change that comes from iterative understanding of the problem domain and iteratively incorporate changes as the unknowns become known.  This is scope creep, but it is not bad, and should be planned for.  Your team will fair far better technically and financially when necessary scope creep is expected, planned for, and then analyzed and documented as part of your iterative development process.

    Posted at 26 January, 2010 | By :Brian Haas | Categories : Functional Specs | Requirements Management |
  • The Past, Present and Future of Requirements Documentation

    Do you remember the days before Agile changed the software development discussion? Back before waterfall wasn't the term coined for all things bad about software development.  You should. It wasn't really that long ago.  Back in those days, believe it or not, there... gasp.... were successful software projects.  But how could that be!  Any time spent in today's software blogosphere would have you asking that question for sure. Successful projects have always been worked through some level of iteration. There just hasn't always been a recognizable methodology name for it.

    YTTBlog1

    Back in those long lost days of yesteryear it would have been unthinkable to initiate a software project without any documentation.  Today, it seems almost unthinkable to document anything. Tomorrow, we think that today's experiences will bring about a resurgence of the importance of software requirements documentation.  These documents will not be created and managed like they were yesterday though. Iteratively creating and maintaining requirements documentation will be the way it's done.

    But what does it mean to iteratively create documentation?  Isn't all documents inherently created iteratively?  Iterations in requirements documentation are as much a mindset as it is an action. Its accepting the notion that documents are never finished, and that acceptance does not have to mean finalized.  Yesterday, a requirements document was written with the expectation of completion.  The document was completed when it passed a thorough stakeholder review.  Upon completion, strict change control was set in place, requiring the organizational equivalent of an act of congress to modify.  This type of requirements documentation is probably familiar to you, and it is not an iterative requirements doc. Authors of requirements docs that cannot be easily changed have an overwhelming burden to continue analyzing beyond the point of effective prudence.  These documents take a long time to "complete" and once completed, they are not maintained due to the organizational resistance to change.  These documents are often very expensive to create and filled with inaccuracies and bad assumptions. Instead of providing clear guidance, accurate estimates, and minimizing scope creep, they creating more harm than good.   This is precisely what has lead to the agile wave and a constant search for a better way.

    The "better way" is not to abandon documentation all together, as desirable as that may be to some.  Requirements communications always live longer than the verbal discussion they are born in.  If they are not captured somehow, problems later in the software development cycle will surely ensue.  If requirements documentation can be viewed as an iterative communications medium, a capture of conversation, and not a stone tablet, your documentation efforts will be worthwhile and lead to less scope creep, rework, and higher quality software.  Welcome to the future.

    Posted at 6 January, 2010 | By :Brian Haas | Categories : Functional Specs | Requirements Management |
  • Requirements Management - Look Ma! No Tools

    Do you ever wonder why the most often used tool (by far) to capture software requirements and write specifications come in the Microsoft Office Suite?  Or why most requirements experts consider themselves to be tool agnostic?

    Dilbert.com

    With poor requirements consistently cited as the cause most often attributed to failed software projects, one would think that teams large and small would be looking for a means to improve requirements and specifications. Surely there is a tool that can solve this problem! And judging from the price of most requirements tools, vendors seem to think that the price of project failure makes a good argument for steep tooling costs. I have been on many teams where the desire was there to use requirements tools, but the budget was not.  So despite the cost and risk of failure, MS Word was what we used.

    With over 90% of business analysts using tools not designed for requirements analysis (aka, Word, Excel, PowerPoint), it would appear that the market has not yet turned to tooling to help solve the problem.  Industry-wide usage statistics would certainly back up an argument against investing in requirements tools.

    So if requirements problems aren't solved by tools, perhaps it can be solved by methodology.  There are plenty of those too.  Agile is the backbone of the latest best methodologies.  When it comes to requirements and documentation, perhaps the agilists are on to something.  Perhaps the best solution to the requirements quagmire is to ignore it.  Or at least de-emphasize it.  If requirements analysis is consistently done so poorly, just skipping it all together and using the time and expense that has traditionally gone to requirements gathering to just talk about it and code will lead to higher success rates.  The record so far does indicate fewer failures. (Do fewer failures mean more successes?)

    Ignoring methodology for a second, when one seeks to improve their requirements process, they find techniques, and not tools.  That's because users and subject matter experts just can't tell you how a visionary software product is going to solve their problems. For most, the first time around full-circle in the effort of requirements elicitation and elaboration turns into significant frustration, as they hear the proverbial "That might be what I said, but it's not what I meant."

    Until we learn to dig and get to the "what we meant" part we'll produce poor requirements documents in any tool we use, even tools designed to "coach" techniques. The flip is true as well.  With some experience, quality requirements documents can be created in any tool. This is why requirements experts can teach elicitation and be tool agnostic.

    Accepting where the true challenge is in requirements management, we can identify the ancillary difficulties encountered in the process where tools can make a significant impact.  Tools that help manage the sheer volume of requirements that often arise and keep track of those requirements to ensure that they are represented in documentation (traceability).  Tools that help in ongoing maintenance.  Tools that help in communicating necessary change.  These are the difficulties that tooling to can solve.

    When considering requirements tools, recognize that there are no silver bullets. The real challenge in requirements gathering can only be solved with knowledgeable and highly skilled people. Recognize where in the process tools can help people improve the efficiency and quality of requirements work and adopt tools for those issues.

    Posted at 22 December, 2009 | By :Brian Haas | Categories : Requirements Management |