1

Suppose that you are in the phase of requirement elicitation (discovery). You have already interviewed your customers and created use case models to discover as many requirements as you can. However, you strongly suspect that there are some implicit requirements (e.g., domain knowledge that is so familiar to customers that customer find it hard to articulate or think that it is not worth articulating). Describe a requirement elicitation technique that can help you surface those implicit requirements.

Thiş is a question from my software engineering sample exam.

I understood that implicit requirements are the things that users are going to expect that were not captured explicitly.

But what is requirement elicatation technique ? Should i interview with customers ???

Improve this question
1
  • 2
    It's sad that this question is being downvoted and that folk are voting to close it as "too broad". Requirements capture is the single hardest, yet most important, part of software engineering. I can only assume that folk are being negative through a fear of how hard it is. Not helpful, but understandable.
    – David Arno
    Commented Apr 18, 2018 at 6:41

3 Answers 3

Reset to default
6

Show them what you're thinking.

You can try writing up your understanding in your own words but prototypes are my favorite for this. I've refined the design of websites using paper, scissors, and tape. Anything that lets the customer quickly see what you have in mind will work. Get your understanding in front of them as fast as possible. Don't even try to be right the first time. Try to be wrong as quickly as possible.

Showing the customer how you got it wrong will elicitate the missing requirements. Then do it all again.

Improve this answer
5
  • Spot on. It simply is not possible to accurately capture all requirements in advance. So don't even try. Get a basic set of their most important requirements and build a wireframe/mockup of how you'd express those requirements as a product. Show it to the customer. Based on their feedback (which will reveal new requirements) build a prototype. Show that to the customer. Take their feedback and build a minimal viable product, Show them that, And so on until they are happy that what you built was what they wanted (rather than what they asked for).
    – David Arno
    Commented Apr 18, 2018 at 6:36
  • "Try to be wrong as quickly as possible": how do you do these on purpose? I tend to see it happen naturally, but I've never made an effort for it to happen. Is there a trick to this?
    – leokhorn
    Commented Apr 19, 2018 at 7:07
  • @leokhorn the trick is to swallow your pride and quickly make something that represents what's been asked for. Resist the temptation to meet unexpressed requirements and create more work for yourself fixing imagined problems.
    – candied_orange
    Commented Apr 19, 2018 at 7:15
  • @CandiedOrange: I see! I call that "playing dumb" by not filling any gaps in what's asked. Though I prefer to ask "innocent" questions that I know will force the customer to clarify immediately.
    – leokhorn
    Commented Apr 20, 2018 at 11:34
  • @leokhorn that works as well. Of course it's not like you have to refuse to fill in any gaps. But many over eager developers shut down requirements gathering prematurely by deciding that they'd rather make up their own requirements then continue listening. Listening is hard but it ensures you're not just writing code for yourself.
    – candied_orange
    Commented Apr 20, 2018 at 11:41
4

One possible option is to actually walk a mile in their shoes. Ask them to let you do the job they want to do with the old software (or without any) for a day. Maybe it's not possible to actually do the job, maybe it takes a skillset, education or clearance you don't have, but then go and observe them.

Many things are blindingly obvious when you actually experience it. For example, every guideline will tell you how large a button should be... but once you are in that warehouse at that specific station and you notice that you have a big knife in one hand and a big glove on the other, you know that that button will need to take half the screen for people to work easier, no matter what the standards of your framework say. You will likely not get a person saying "that 'Next Item' button must be usable with only one hand free and that hand has a mail glove on". Because the people sitting at a desk with you in a nice shirt discussing the requirements probably never worked down there on the floor. But you will see it when you do.

Improve this answer
3

@CandiedOrange nails the most important one, but there are a few more, particularly if this is for an exam :)

One thing is to build a more structured representation of the requirements, a class, state, or dataflow diagram or a domain model. This can help you see where gaps are and you can then ask for clarification. There are also very formal specification languages like Z.

Another is to observe their current process. This includes things like looking at their existing systems, contracts with customers, literally watching people work, and even looking at their marketing material to make sure that the new system will provide the features they need/are promising to others.

As useful technique I've picked up to get people thinking more specifically is to try to find dubious functionality implied by the current requirements and then ask the customer. "So really anyone can edit anyone else's timecard or do we actually need more than one access level?"

Here is a pretty good overview from an academic perspective.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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