New answers tagged

0

Let's do a thought experiment: imagine you want to build a house from the ground up, and you know nothing about construction. How do you describe the requirements to the builder? Even if you could, they would likely be vague statements like "I want to make sure I have plenty of closet space" and "I want a modern kitchen". Obviously you can't be expected to ...


0

If you feel a prototype is too polished and will confuse the client, just sketch it out. You can have multiple versions if you think that will help prompt the client. This will fulfill management's need for you to do stuff without creating a bunch of code that you will throw away (If you know what's good for you.). The client also needs to know that they ...


0

At some point, the developers need a set of requirements where they can develop an application and later check whether it meets the requirements or not. And then they go and build an application that meets the requirements. And it is a really, really good idea to have requirements where an application meeting the requirements benefits the business :-) ...


4

From my experience. I would not spend a single minute developing. Not even a little piece of code. At this stage, where customer doesn't know what he wants, it's really important to do a good job of consulting. It's as important for them as it's for you. There's a need behind any project (some times it's not clear or evident) and there's also a business (...


4

It is difficult to advise without being able to judge the mood music accurately. Either: The business users and management aren't doing their jobs and are just kicking the can down the road for the devs to deal with (and so they can kick the devs when things go wrong). Or: They're really not sure what they want and need to be guided by the ...


7

Write a document proposing 2 or 3 solutions along the lines of : "To achieve 'high level principal x' we propose 'Technical solution y' which will 'thing techincal solution does'" Get the customer to sign off on the ones they want and implement.


1

I have some background in requirements engineering, though for these kind of unsharp requirements it is in my opinion required to take a different view on on the requirements. There are various methods for requirements elicitation, grouping, analyzing, refining etc. There is however a common pattern to most methods and practices: You need to take different ...


9

To start, I'd say you don't have sufficient information to write the requirements. Your task would be to gather specific details. When you're tasked to improve performance, the first thing you should probably do is measure what the current performance is and record these numbers. Then, you should decide together with the business what the target is. If you ...


5

I see two cases: you have requirements for the software or you don't. In your particular case, you don't have performance requirements, but you do have functional requirements. You should update your requirements specification to add performance requirements and associate those with specific pieces of functionality. When you're writing these performance ...



Top 50 recent answers are included