Nowadays everybody wants to be agile. In every team I worked with, the shape of agile was different. Some things are common - like daily stand-ups or planning, but other parts vary significantly.

In my current team there's one detail which I find disturbing. It's lack of functional requirements. Not only there's no written form of expectations but also in the tasks it's rather vaguely defined what needs to be done.

The project goal is to rewrite of the old system using new technologies. Old system doesn't have any reasonable documentation as well. For sure up to date one doesn't exist. Business owners' description of requirements is - let's do it in new implementation the same way as old. It seems reasonable but it's not. Old system is kind of spaghetti code and extracting business requirements from it is costly. It seems that the situation affects planning in a negative way. For sure it's prone to mistakes and bugs in new implementation (omitting some details).

Therefore I'm thinking - is it truly agile to have no business requirements in case of rewriting old system?

  • 1
    Will the old system be in use until the new system replaces it, or will both systems be used simultaneously, with the new system gradually replacing functions in the old system? Jul 11, 2019 at 12:39
  • 1
    @GregBurghardt second option Jul 11, 2019 at 12:41
  • 1
    Well, what does your team plan to do? Are you going to gather them, talk to business people, etc.? Jul 11, 2019 at 12:54
  • 2
    Also, remember that you can only fix two of the three constraints: time, effort and scope. If time is fixed (as you said in your comment) and effort is fixed or at least capped (is your boss willing to hire infinite developers?), then either scope is not fixed and you guys should do what you can in the fixed time that you have (this is what Scrum does with Sprints), or you should accept failure and move on (possibly to another company where bosses either understand software development or leave it to the people who do) Jul 11, 2019 at 21:53
  • 3
    I would call that fragile, actually. Jul 12, 2019 at 10:54

6 Answers 6


Whether or not lacking functional requirements is agile, it is a recipe for disaster. You cannot rebuild a system when you do not know how that system works.

You need to tell the business owner that you have no idea how the old system works.

Your best option is to work with your business owner or a few experienced users to understand the business processes at play, and develop your own acceptance tests. If you can work with some end users you might get more feedback about how the old system works.

Failing that, you'll need to do some exploratory testing in a non production environment to gather your own requirements. Many times when a business owner says "make it work like the old one" they are constrained on time, and are not able to help you out like a business owner should. You need the expertise of some seasoned users, or a whole lot of manual testing on your part to understand how the old system works.

Inform the business owner that a lack of requirements and understanding of the old system will greatly increase the time it takes to rebuild it — around triple the time or greater. Faced with the increased timeline and cost, the business owner will either give you the expertise required to gather requirements faster, or decide the rewrite is not economically feasible at this time.

You'll get one of the following:

  • Proper requirements and a faster development cycle
  • Time to gather requirements and rebuild the software
  • A new project that won't end up being a black mark on your career
  • Great answer, Greg. Very reasonable, professional point of view. Unfortunately there's some detail which make situation even worse - deadline for part of the system is fixed due to external requirements. Anyway, as a general guideline it's great advice. Jul 11, 2019 at 12:55
  • 6
    @Landeeyo: That's a tough spot to be in, having a crushing deadline. That's why it is all the more important to communicate a lack of requirements will cause you to miss the deadline. Risk of missing the deadline could be the fuel needed to get you what your team needs. Jul 11, 2019 at 13:28
  • 1
    Obligatory Dilbert Jul 12, 2019 at 10:55
  • This story is getting weirder, like half of it is made up. Prefixed deadlines don't exist in software development. The deadline is at the point where the financer of the project gets impatient and loses faith in a good outcome. That is when the plug is pulled and that moment is never known upfront. Being agile means you will make sure this moment comes sooner rather than later, saving the financer a lot of money, known as failing fast. Jul 13, 2019 at 8:02

Agile doesn't change the need for functional requirements, but it does generally change how you gather them. The non-agile way is for someone to go through a long process then give you some sort of document containing all the requirements for the system.

The agile way to gather requirements is to work together to specify the requirements for a small increment of the system, build it, then get feedback and do the next increment. In your situation where you are having trouble getting the business owners to initiate the process, I would start by spending maybe half a day exploring the part of the old system you want to work on next, and generate a list of questions about the requirements.

Then sit down with your business owners and ask them the questions. Some questions will be easy for them to answer, some are easier for you to answer by looking at the code, and some are difficult to answer either way. Break the difficult questions into smaller and smaller pieces until you reach something that can be answered.

The goal is to get just enough of your questions answered in order to build something, get feedback, and restart the process. Remember, the smaller your changes and the shorter your feedback cycle, the less of a big deal it is if you build the wrong thing.

  • 1
    One could certainly argue the point that this sort of situation is perfectly suited for agile. You have a weakly understood system that you're trying to replace. So, understand some small bit (acceptance criteria), built that small bit (sprint), and get feedback (demo). Lather, rinse, repeat. Jul 12, 2019 at 18:56

Capturing requirements is an essential part of any (successful) software project. But writing a requirements specification isn't.

  • A documentation-centric approach can end up like a game of Chinese Whispers: a subject matter expert voices a requirement, an analyst writes it down, a dev tries to write something that meet's the analyst's description, the end user is confused because the software doesn't solve their problem.

    Agile techniques suggests that developers should gather requirements directly from the subject matter experts, usually the end users. There are a variety of techniques to do this, for example by talking through an example scenario with the SME. Devs are good at spotting edge cases and asking the SME to clarify how the software should behave in that edge case.

  • Instead of gathering all requirements up front (and thus risking large misunderstandings), agile teams will likely start with a small slice of requirements, build a prototype, and use that to gather feedback for the next iteration.

  • As the understanding of the requirements shifts over time, a static requirements specification will fall out of date. How can this be prevented?

    By expressing requirements as runnable tests. It turns out that “readable specification” and “runnable tests” are not exclusive concepts, but can end up being one and the same document. E.g. Cucumber and other ideas out of the BDD space can be very helpful here.

In the case where you are rewriting an old system, the original system can be a great source of requirements. But which aspects are relevant? Are its niche features even being used? Which bugs must be reimplemented for compatibility? There's usually no workaround for talking with the end users.

Having a working system lying around can also be very helpful for testing the new software, but that is unrelated to any agile-ish concerns.

Note that fixed-scope, fixed-time projects with looming deadlines are the antithesis of agile. The normal agile approach is to pick a sliver of functionality and first deliver that, then iterate. The most important stuff gets done first, less important stuff later (or never). If everything is important and MUST be done ASAP, then nothing is important and the project is unlikely to deliver anything.

In your situation, the lack of requirements is not an agile feature but more an average case of organizational dysfunction. If you want the project to succeed, you will need to find a way to cut through this dysfunction. E.g. urge the business owner not to write a complete requirements document, but try to set up a meeting where they explain their requirements for the most important feature. You can look at the old system for details. Then implement that feature, and iterate.


Here's how we did it. We talked to the owners. We talked to the Managers. We talked to the users doing the work. What we found by sitting down at a user's desk and watching (and asking questions) was amazingly useful. The managers knew which users we should sit down with.

We discovered that some parts of the system worked very well indeed, and we could easily write enough requirements to get started the designing and coding and test cases and so forth, but other parts had some nasty workarounds that the users on the floor were using, which the managers and the owners were not aware of. For these parts of the old system, we went back to the business and talked about workflow and processes for a bit before we could nail down what the smaller tasks should be and thus could break them up into the units that our agile method wanted.

So while Agile could quickly take off on some parts of the system, others had to have a bit more thinking and documenting before we could start.


Gathering requirements in an Agile framework and no-one has mentioned User Stories? A user story is essentially a high-level definition of what the software should be capable of doing. Typically, any feedback or request that comes from the business or end-user can be written as a user story. ... You can think of acceptance criteria as the functional requirements that support a user story.


This question hints at what went wrong with the agile movement. It's no fault of the person asking the question; I fall into this trap all the time because years of corporate life trained me to.

The trap I'm talking about is thinking that there's a prescribed and correct Agile way to do things. This might be because people think Agile exists. You can't do Agile any more than you can do Pragmatic.

Not having "functional specifications" or whatever, sounds worrying, but it might not be. How much detail do you need to start? Security and performance are the obvious ones that are known up front and apply all the way through. Otherwise, is it an Options Pricing engine or a clock app?

Will there be continual release, discussion, learning, going back and changing the software? Are you building soft ware or hardware?

Developers working in a waterfall process often don't become involved until a later stage, which is a problem. Involving them earlier or from the start means they're privy to things being unclear, undefined and half-baked, which seems to upset long-time developers, when in fact part of their job is to ask questions, such as "what are the functional requirements for this thing we're going to build?"

Identifying holes in the plan isn't about finding fault, its just software development.

For this reason, I love Guy's answer.

Not the answer you're looking for? Browse other questions tagged or ask your own question.