Eliciting Requirements as a Client

Question

Background: I am a computer science student and am currently employed as a programmer for a health institution. Recently we discovered the need for a project which is beyond a 1-man job (I am their only programmer), so my boss asked me to assist his working group to get a clear grasp of our requirements which we would then take to a software company.

We are now in a phase where we would like to get some offers from 2-3 software companies in order to estimate how much functionality we can get for how much money (which is both flexible within a certain margin) and I am starting to wonder how detailed we have to know what we want before doing so.

To put that to scale: We started with the idea that 'we need to get rid of this paper pile and enter stuff directly into a computer to speed up the process' and now have an 11-pages requirements elicitation document with a fairly precise description of what we would like to achieve in business-terms plus some non-functional requirements but no use case specifications or GUI mock-ups which show the changed business process.

Since the requirements elicitation document is usually a fairly large part of any software project, I wonder where to stop. Would you recommend me drafting some use cases to get an even more distinguished idea or would I just be doing the contractor's work?

Answer 1

It sounds like you've done a great job detailing the requirements. My suggestion is to assess why you are hiring the outside firm. If you are looking for new ideas and innovation, take care not to 'tell' the firm what to do in the requirements. If you are looking for someone to grind out the work, you need to detail every feature and process.

If you aren't sure why, then go to your boss and get clear on that. If you hire a company to do the grinding and they are an innovative design group (or the other way around), you'll struggle to achieve success.

Answer 2

Don't draw a line between yourself and your contractors. Instead, try to setup an open environment where information about requirements flows effectively, between all parties. The document about requirements (either a set of UML diagrams or MS Word files or whatever it is) has to become a live platform for all communications between all project participants.

And again, never stop to elicit requirements and develop the document. Read more about iterative and incremental software development paradigms. Also I'd recommend to read Requirements Development process area of CMMI for Development 1.3.

Answer 3

There are basically two approaches you can use here:

1. Try to be pretty specific in terms on what you need. If you know you requirements well then just try to write down everything you know, or you think you know. It is more important to put your knowledge into paper in some way and not the exact way of putting it into paper. So go add some use cases but only as long as you believe it has some value, which basically means both you and a vendor would know better what you're building.

   Also note that often one of big problems regarding projects is misunderstanding or misinterpreting the scope by one of sides or, in other words, making wrong assumptions. This means the more detailed is the scope the better.

2. As an alternative you can just accept the fact that the point in time when you know least about project is at its beginning (in your case now) and plan that scope, to some point, may change. Then you'd like to find a vendor which wants to build the project agile way. In short they will be building the project iteratively and you will decide what's the next thing to add basing on what you already got and not only on idea you had at the very beginning.

   This way you will probably get what you want but you also share consequences of frequent scope changes as you would basically pay for them. This is because this kind of contracts base, at least to some point, on time&material rules.

As a rule of thumb - the more sure you are about what you want to get the more you should lean toward the first scenario and vice versa: if you aren't exactly sure what you want to build you should consider second scenario as a way to go.

Answer 4

To add to Perry's excellent answer, I'd like to say that the level of details you need in requirements is entirely dependant on the level of proficiency the contractors have in many different ways. Just to quote a few:

1. do they know the subject area?
2. do they usually work at that scale (is it below their run of the mill project, just what they do, or it is a stretch)?
3. how do they like to work? Some guys are good with getting their own requirements, others need them spelled out.

---

The other way to look at it entirely is to take a risk-based approach. What are the risks of things going wrong with one particular set of requirements, what is at stake? A chapter that is more critical to your operations (higher cost if anything goes wrong) needs to be more detailed. A chapter that is less critical needs less detail.

In a particularly important part of your requirements, describing what the user expects (or at least what benefits the user expects) could be a good way to convey intent. Call it a use case if that's your way to think about it, but it does not necessarilly need to be as formal as that.

---

As to doing the contractor's job, there is no rule to say you can't do your share if you have the knowledge. But keep in mind that some contractors will want to put their ideas forward so you may be doing work that will be wasted. Or it may be the case, if they like what you have done, that it will save you all time and effort. That depends on the relationship you will build with the chosen contractor, on how well your work stands on its own, and how well you or your boss will negotiate the contract.

I have saved a former employer of mine 8 times my yearly salary by doing 3 months of testing that therefore did not need to be repeated by our key supplier. It did not go brilliantly with our supplier, but 1/ they finally accepted the facts and got more business afterwards anyway; 2/ my bosses were happy.

That little personal story just to say that circumstances can be on your side or not and saving your boss money should always pay off, even when it is at the expense of slightly more difficult relationships with your supplier.