I have been asked to complete a project without any concrete specifications

Question

I work in the software development domain. My team leader and manager have asked me to complete a project after calling a single meeting to discuss project details. In the meeting very little information was available and on asking for clarification they responded that "you should create it your way".

I have no problem with that but after completing some milestones they are repeatedly calling for major changes in project. I have no objection to this but if I have a clear idea about project at the start then I can create a strong and dynamic structure for the project with clean code.

Now what happens is I have to make patches for functionality in code because they need features in very sort time and I think this kind of work kills productivity and creativity of developer.

Please suggest what should I do in this situation?

Answer 1

First: Welcome to this little thing I like to call "real life".

Software developers are always saying that before we start a project, all the requirements should be fully nailed down, from detailed descriptions of algorithms to screen mock-ups, and once development work begins, no changes should be allowed. When the product is delivered, we will of course fix any deviations from the written requirements, but no changes that involve a change to the requirements are permitted.

Yes, this would make life much easier for the software developer. And it's an absurd demand.

Imagine that you wanted to buy a car. So you go to the car dealer and find that it's just an office with one guy behind a desk. He hands you a blank sheet of paper and says, "Write down here exactly what you want in a car. We'll then find a car meeting those requirements and deliver it to you. Once you sign the paper, we'll start searching for a car, so at that point no changes are permitted." "But," you say, "I have a general idea what I want, but I'd certainly want to try out a few different cars, take them for test drives ..." "No, I'm sorry," he says, "That's not possible. Just write down what you want and we'll get you a car meeting those requirements."

Now suppose that on top of that you have never driven a car before. How would you know what you want before you tried it? Things that seem like a good idea on paper may not work out so well in practice, etc.

I wouldn't be worried about vague requirements, PROVIDED that everyone involved understands that the requirements are vague, that you are going to have to fill in the gaps, and that when they see the decisions you've made, there WILL be some decisions that they don't like and things will have to be reworked.

If this is a loose and co-operative environment, there should be no problem. You produce something, bring it for review, they tell you what they like and what they don't, you make changes, maybe go in many cycles. I've done many, many projects like that in my life. Often the user has to try out the software to see what works in practice and what doesn't.

If the boss or the client are making unreasonable demands, or if you don't know what the environment is like, then you need to get things in writing to protect yourself. I've done some projects in my life where the boss or the client says, "I don't know what all the requirements are, you just make something up". Then I make something up and when I bring it back they scream, "What! That's not what I wanted! What kind of moron are you? Surely it was obvious that ..." and then proceed to give a whole bunch of requirements that they never mentioned before and that were not obvious to me at all. In that sort of environment -- even if it's not yelling and threats of firing you or cancelling the contract, maybe it's just expressions of severe disappointment and frustration -- in that sort of environment, write up a paper describing what you propose to do and give it back to them for approval. If you're lucky, this will lead to discussion of what the real requirements are. At worst they say "yes yes whatever" and brush it off. But at least at this point, when you then come back with the software, if they say, "That's not what we wanted", you can bring back the document and say, "Oh, I'm sorry, this is what we agreed I should do. See, it's written right here, and you approved it." In a friendly environment you say this in a friendly way; in a hostile environment you may have to be more forceful. Either way you then say, "Okay, so what changes to the requirements do you want to make?" Then put those in writing and start another cycle.

If the boss or client expects impossible turn-around times and blames you when impossible demands are not met, then frankly it's time to start looking for another job or another client. Or if you need this job/client badly enough, you suck it up and take the abuse. (I have fond memories of the time my boss asked me how long it would take to convert a large, complex system our company had built years ago from an old computer language to a more modern language. I started trying to think out loud a bit, we'd done such a translation on another product so we had some experience, but no one in the company today was familiar with this product, blah blah, and then he said, "I don't need an exact answer, just roughly: two days? three days?" I was flabbergasted, "Umm, no," I said, "The question is how many months." He walked away muttering.)

Answer 2

You need to push back. Get time on their calendars. Ask questions. Ask a lot of questions. Ask so many questions that they get tired of you and will give the detail you need.

If they don't know, propose specific requirements and get sign-off. Document their answers and send the answers back to them for confirmation. That makes it clear that the cause for change and delay is them changing their minds, and not your development.

When they say "build it your way," what they really mean is "do something that I can look at and change." It's much, much easier to revise and change requirements before they are implemented.

Answer 3

Generally speaking, when the client requirements are very vague, what you should do is write down what you're about to do (i.e. technical and functional specifications) and have them validate the document . This way, if they want to change something during the project, you can point out that this is not what was agreed and charge them for it. At least equally important is the fact that they can't blame you for doing it "the wrong way".

If your project is not too advanced, I'd still try to make this happen. It may seem like a loss of time on the short term but it will keep you from a lifetime of changes implementation.

If you're almost done (discarding the endless list of soon-to-come changes obviously), well that's more complicated. You're looking at damage-control here. Have, preferably in written, your manager acknowledge that. You don't want to be a scapegoat if the project becomes really messy.

To put it bluntly, this looks like poor project management to me. I'd have a talk with the manager to avoid this situation in the future

Answer 4

Marv, I think most of these answers are bunk.

This isn't the reality of software development. It's the effect of not managing a software shop well enough.

Requirements aren't the answer, because requirements change. Whether it's because the people signing off change their mind, or that they never had an idea of what they wanted in the first place, it's irrelevant. Even the business itself can change priorities, forcing requirements to shift.

Only one person seems to have suggested Agile. That's a good start, but Agile requires a lot of buy-in from a lot of people, people who have to do homework. Clearly, you are not working with people who don't want to do their homework.

So, borrow from Agile. Have these stakeholders attend conversations in which you drive the creation of stories (http://www.mountaingoatsoftware.com/agile/user-stories). Keep these definitions in their language, so that there's no confusion over what they agreed to when it's reviewed 3 months later. Expect rounds of story-making, keeping them high-level/broad at first, and breaking up stories into smaller ones over time as you find you need to. Smaller stories means finer scopes of work, and helps make solvable problems.

Armed with a set of stories small enough for you to give comfortable estimates, you can drive a schedule and prioritization for developing your project, regardless of how much stakeholders do or do not help. Make sure the stories are stored in a transparent way. And when people want you to shift from "working by stories", then push back.

Mockups, proposals, PoCs, all that are fine, but even they must come from an understanding of what you're going to build for a living. Otherwise, it's just shooting in the dark, believing that one day you get a lucky hit. Take the problem by the horns, storyboard the project for them if they won't do it themselves.

Answer 5

"Fail early, fail often."

When you have minimal requirements, build a minimal system, then show it off. Demonstrate it and its features all along the way, and request and expect feedback that will alter your trajectory.

Yes, many developers like you want a pristine specification, whereupon they'll go to the tower, and some time later emerge with the correct implementation, ready to receive the next project.

However, you've joined a company and team where you are instead expected to run with minimal input, jog for a bit, come back with questions and demos, and jog for a bit more.

There is an element of inefficiency to this process. But often business requirements and needs dictate it. If they waited to create the perfect specification, the project wouldn't be done in time, and would still need modifications anyway because no one can predict the future.

Iterative development might not be your cup of tea, but as you'll discover, it's much, much more common than the perfect spec development.

Communication, frequent user/customer/supervisor testing and feedback, and a willingness to roll with the punches will become great skills to have if you develop them.

Answer 6

At the point you start a project, you know the least you will ever know about it. The consumers of your project also know the least they will ever know about it.

They can give you a pie-in-the-sky "here is what I think it should do, and here is how I want it to do it", but the odds are they are going to be wrong, especially in the details.

Similarly, if you take a design and make a 2+ month development plan to implement it, then go off and work on it, you are almost certainly going to not follow that plan. Parts are going to be harder or easier than you think, other parts are going to be pointless when you get to them, and as you work on the project you are going to gain expertise at that project.

A week in you'll have a better idea of the plan and lots of tweaks. A month in you'll probably think your plan was stupid.

Your customers/bosses have an idea of what they want. They aren't experts at the thing they want to make: at best, they are generalists who know how to solve similar problems, but the only way to become an expert at creating a piece of software is to create that piece of software. If they already had created that piece of software, they wouldn't need you.

Your job is to become an expert at creating the piece of software. What the software does, initially, is going to be vague. They don't really know, and you don't really know. So you iterate: you work out what you think they want, you ask them if that seems reasonable, you implement and get something in front of them as soon as possible. Depending on who they are, you polish different parts, and leave other parts unfinished.

Then you get feedback. They'll like some parts, think other parts are garbage, and think other parts where a waste of time. You go off and you change your software -- maybe you even scrap the work and start again (because now your expertise on writing that first part has gotten much better -- you just did it, and you probably learned something from that) and get to the same point faster -- or maybe you just tweak it and add what they like, and changed what they want.

When you get their feedback, get them to say what the most important thing is they want improved. Get it written down. Ask for what is more important (get it in an ordered list). Say you'll get back to them with prototype estimates in a day or two. Guess how long it will take to prototype the top few features they want, ask them if they are ok with a prototype (NOT a finished version) being ready to show to them in X days (include buffer for errors) of one of the top 2 things they want.

Then show them your prototype, ask them if they want it finished or removed from the solution. Depending on who they are, you may want to make it clear by how the app behaves that it is a prototype. By this time you should have a good idea how long it will take to polish the prototype. They can ask for more changes prior to "finishing" it, or they can ask for it to be polished. If they ask for more changes, go back to the previous thing of priorties.

This is basically developer-driven agile, where you actively engage in making deals with your consumers/boss. They get frequent prototypes, and are asked to give feedback often. You have to make sure that any prototype can and will be removed if they don't ask you to polish it, and that they know your prototypes aren't that close to completed features.

By doing this, your expertise at writing the application grows, and their understanding of what they really want grows, as you develop the application.

If you ask for a complete specification up front, the decisions get made before you know what works and what doesn't work.

Answer 7

A software team needs not only developers, but also requirements engineers, testers, and a few other roles. It is entirely possible that on a small team, the same person wears many hats at once. But note that the role of a requirements engineer requires a different skill set than that of a developer. If you try to create requirements blindly, without knowing the right way to do them, you'll be very inefficient, basically coding the wrong application in most of your developing time and then getting frustrated when you have to scrape it and start again.

I would suggest that you get some of the skill set needed by a requirements engineer. In your current job, you will become better at the tasks you have been saddled with. In future jobs, where requirements specification may be created by a dedicated requirements engineer or by a consensus within the team, or cobbled together by a client, having this skill set (which will interface with your purer developer role) will make you a more valuable team member and will allow your team to work more efficiently together due to better communication with you.

The best way to start is with a comprehensive textbook. My personal favorite is Ian Alexander's Discovering requirements, a very practical text which is easy to follow by beginners. The second read on your list can be Lauesen's UI design for engineers. The title might sound aged, but what you'll learn from it is now known under the buzzword UX, which is a plus to have on your resume nowadays. And no, that's not only about the interface, it covers all requirements which are perceptible to the user (so including the question which functionality to include).

At the same time, educate your managers that it is real work. This means that 1) if they expect you to do a job which needs 10 hours worth of requirements analysis, you only have X-10 hours left to code. And 2) that, just as any other process, it turns input into output, and you need to be given access to the input before you can produce a specification: in this case, any information you can get about the future use of the application you are working with. Even the biggest RE whizz cannot create a good concept if he is not given access to real users. The books will tell you which sources you need access to; try getting as much of them covered as possible.

Answer 8

I think what this comes down to is educating clients and management.

Changes becomes more expensive the further along the project is

You can consult nearly any software engineering textbook to get the "relative costs of fixing errors in the software lifecycle graph". It basically says that the further along in the project you are, the more it costs to make a change. So why would you not fix issues in the planning stage whenever you can?

Code Complete mentions that the majority of the cost of a project is in the coding - so if you need to repeat that several times, the cost of your project can easily spiral out of control.

Plan just enough for the complexity of the project

There are several metaphors appropriate to software engineering. My personal favorite is building construction. Unlike building, the amount of planning does not need to be exhaustive - it only needs to be sufficient to the complexity of the product.

• If the project is trivial (like a dog house), then you can ask the builder to "just build it, we can change it later", and that's fine. Changing it is easy.

• If you're building a house, you usually ask an architect to draw up plans first. The client and the architect agree on a design before the house is built. When the plans are accepted, the builder can start. You can still ask the builder to just make it, but he'll need to sketch out a rough plan before starting, and it'll cost you a lot more when he has to fix it.

• If you're building an office block, you better use an architect, or it will collapse. If an incredibly skilled builder manages to make an office block without a plan, asking him to add a sub-basement because you forgot about parking is either immensely expensive, or completely impossible.

You don't need an exhaustive and complete spec before starting. You just need enough to check that what the client has in mind is what you have in mind.

You can't build faster than you can plan

Clients sometimes object that planning would take too long. My response to that is "You want us to build this faster than we could plan it? Planning is faster, easier and cheaper than building, so if you don't think we can plan this out in three months, then we definitely can't build it in three months."

If you do planning early, then misconceptions are cheap and easy to fix. If you don't, then fixing problems later on are harder.

The Agile way

Agile takes a very different approach.

• Instead of taking the waterfall approach once, you break the project up into iterations of a week or two each.

• You still do planning and requirements clarification, but less of it, and you do it once each iteration.

• You get lots of user feedback on each iteration

• You make the simplest changes to the software that can support the new requirements before presenting to the user

• You do lots of TDD to ensure you don't break stuff with your constant refactoring

Death by a million changes

There is a kind of user who likes making a ton of small adjustments. "This font should be slightly larger." "This font should be slightly smaller." "Make this a different color." "Instead of the perfectly good thing we have here, how about we change it to something slightly different."

If that is the case, my suggestion is that you get the client to focus on core functionality first, to focus on bigger changes first. You should also ask them to articulate the requirement that the small change satisfies.

It may well be that there's an important requirement behind the request that you just don't know about. If that's the case, understand the need, and see if you can suggest something that satisfies the requirement in a better way.

Often the requirement is "general ease of use". The answer to "general ease of use" is almost always user testing. Not client testing, mind you, but user testing by about six of the people who will actually end up using the system.

Answer 9

When you aren't getting the requirements you need to start a project, what you need to do is write down every requirement that you need, and get them specified as soon as possible. Let them know the exact requirements you need and, most importantly, which ones will stop you dead from completing the project.

While you are doing this, code as much as you possibly can with what you are given at the start. I cannot stress this enough. Continue to work on what you've been given until you can't anymore. Let them know when you've reached a point you can't get past because requirements haven't been set yet.

There may be a legitimate reason your boss(es) haven't given you the specifications you need - they may need a mock-up done to see how it functions first, they may not have them yet because your users/business analysts are dragging their feet on the exact metrics that you need to follow. Whatever reason they have, even if it's a bad reason, you should still be getting as much of the work done that you can as possible.

Sometimes, requirements will change, and there's nothing you can do about that.

Welcome to the Software Industry.

Answer 10

It is part of your job to handle things like this. A lot of the answers give you some more specific ideas how.

It is part of your job to be flexible. To make code that is patched, yes, but understandable in the first place. And fixable, as you go. your job

It is part of your job to listen to pie in the sky requests, do some coding, having somebody say, that is not the way to code, code the way they want, which doesn't work. Then go back and do it the way that works. Part of your job

I guess the only messy thing that is not really part of your job is to make a complaint that this is inefficient. You can mention it, I guess, or you can try to tie it in, when things are getting later and later, you can suggest certain things, but this is probably not going to work really.

Again, its going to be part of your job to deal with the mess. And be nice. And say,ok, boss, when the whole thing gets thrown in the dumpster. And say, ok boss, when the whole thing has to be pulled out of the dumpster, covered in trash, and re-worked.

Part of the job. If you don't really like it, I suggest you start you own company, hire a bunch of slightly arrogant programmers, and try to sell you services and product and make payroll while your whiney employees are saying, it's patched boss, it's not pretty code boss. so...

I guess one other thing is, people that run business often do not, absolutely, ever, have time for lots of meetings with you. If you can do your job, your going to be able to anticipate some things, be able to fix the stuff you can't, and do it all on your own.

Answer 11

As already stated in other answers, your "clients" (those who have requested the solution you are building) need something they can compare against their requirements in order to fully explore and understand those requirements (the car-buying tire-kicking analogy). That's why they didn't provide complete specifications and started requesting changes after your solution started to take shape.

When the "client" is conscious of this, they may explicitly ask for or allow you to build a prototype and develop a more solid specification based on what the prototype revealed. However, you can end up going down this same road without anyone (you or the client) being explicitly aware of it. The problem comes when you quote on delivery of what turns out to be the prototype, where your client expected your quote to apply to the finished product.

In "The Mythical Man-Month" there is discussion of a "pilot" system. Essentially, building a system once (which will be thrown away) in order to learn everything needed to build the system all over again, the right way, and how often it happens intentionally or not. You may be nearing completion of your "pilot" system, with the "real" solution yet to be started.

Perhaps the best you can do at this point is to document each change request - exactly how you understand the requirement, and your quote of what it will take to deliver it - and be honest. Don't start on any work taking more than a couple of hours on mere verbal agreement. Write it down - even an informal email is better than nothing. You may need to protect yourself from "that's not what I asked for" and "you didn't tell me it would take this long". Simply telling your boss that he should stop asking for changes could be bad politically. Let the growing trail of quoted change descriptions speak for you about how things got to where they are and how you were making your honest, best effort to comply with the requests from your "clients".

Answer 12

Alternatively, draw up a chart or schematic of what you think the clients want. If they want a program that has equation solvers, you might draw up a schematic (UI and all) of a program in whic hte user is presented with a menu, then allowed to press a button to select an equation solver. The equation is then entered into a text box, then the user hits another button to tell the program to solve the equation.

Also, please do yourself a favor and get the client's response in writing. Think of it as a way to cover your butt if the client later says, "I didn't want that."

Answer 13

Communication is best way to resolve your issue. Ask questions that they get tired of you and will give the detail you need. If they don't know, then propose requirements by your self. Document answers given and send answers back to them for confirmation. This way you makes it clear that the cause for delay or change is due to changing their minds. When Mgt. say 'build it your own way' that mean is 'do something that I can look at and change.' Theoretically, software development is suggest that before start a project, all the requirements should be fully cleared, from detailed descriptions of algorithms to screen mock-ups. When the product is delivered, we will of course fix any deviations from the written requirements, but no changes that involve a change to the requirements are permitted. Yes, this would make life much easier for the software developer. I wouldn't be worried about vague requirements, provided that everyone involved understands that the requirements are vague, that you are going to have to fill in the gaps, and that when they see the decisions you've made, there will be some decisions that they don't like and things will have to be reworked. Demands that are unreasonable and made by boss/management or the client, then you need to get things in writing to protect yourself. If the boss/management or client expects impossible turn-around times and blames you when impossible demands are not met, then frankly it's time to start looking for another job or another client.

Answer 14

Give your boss the minimum and quickest interpretation of what little requirements he has given you and present it quickly as a done deal.

Any future unclear requests for change should be questioned making it plain that the change came out of nowhere where you were asked to write your own thing and now it is being arbitrarily changed. Ask for more concrete reasons for any change so you can discover your own requirements and tell your boss that he is reneging on allowing you to do your own thing and push it as his failure.

If, however you have a good relationship with your boss, he may well be giving you a chance to shine - ask him for the means to discover your own requirements, apply yourself, and deliver!