297
My rule of thumb:
the first time you encounter the problem, only solve the specific problem (this is the YAGNI principle)
the second time you run into the same problem, consider generalizing the first case, if it's not a lot of work
once you have three specific cases where you'd be able to use the generalized version, then you should start really planning ...
130
The sound-bite answer is that requirements are what your program should do, the specifications are how you plan to do it.
Another way to look at it is that the requirements represent the application from the perspective of the user, or the business as a whole. The specification represents the application from the perspective of the technical team. ...
102
If you get a set of requirements that are physically impossible to implement as the device does not support and cannot support the wanted functionality, you need to explain this to the person creating the requirements.
You should be respectful and explain why the requirements are not possible to implement (i.e. the touch screen cannot distinguish between a ...
96
A specific solution [...] requires more work in the future if similar requirement is needed
I have heard this argument several dozen times, and - to my experience - it regularly turns out to be a fallacy. If you generalize now or later, when the second similar requirement arises, the work will almost be the same in total. So there is absolutely no point to ...
78
The formal answer is you misunderstood agile, agile does not dictate requirements, stakeholders do. The core of agile is not to carve your requirements in stone but rather have them emerge as you go, in close contact with your client, benefiting from progressive insights.
But that's all theory. What you have witnessed is indeed a common trait of many ...
74
There doesn't even seem to be a place for attractive qualities in agile.
You are comparing apples and oranges. In traditional waterfall, if your requirements say you need the must-haves, you get a Fiat. If the requirements say it has to be top notch, you get a Ferrari.
The same happens in Agile. If your requirements stop at must-haves, you get a Fiat. If ...
65
TL;DR: it depends on what you're trying to solve.
I've had a similar conversation with my Gramps about this, while we were talking about how Func and Action in C# are awesome. My Gramps is a very old timer programmer, that's been around source codes since software was run on computers that took a whole room.
He changed techs several times in his life. He ...
answered Nov 30 '17 at 20:01
T. Sar - Reinstate Monica
1,9241 gold badge10 silver badges17 bronze badges
55
User Stories are not system specifications or functional requirements. Rather, they are the beginning of a conversation that can lead to such specifications or requirements.
Accordingly, I would expect there to be overlap in the system implementation. User Stories are not meant to describe such functional overlap or to eliminate it. The purpose of User ...
52
Though they have their own internal IT team, they have asked me on
what will be the hardware requirements for the live servers eg. RAM,
32 bit or 64 bit.
Perhaps they figure that as the developer, you have more insight into the app's requirements than they do. You've presumably been running the application and know how much memory it requires under ...
52
To be honest, after spending close to two years immersed in Agile development, I still think "user story" is just a fancy term for "functional requirement".
It's different at a superficial level, e.g. it always takes a certain form ("as an X, I want Y so that Z..."), but the key elements - identifying the stakeholder and the rationale - are also inherent in ...
38
Requirements document what is needed - they shouldn't specify the how, but the what.
Specifications document how to achieve the requirements - they should specify the how.
In many places these documents are not separate and are used interchangeably.
36
There are many situations in which these two might be in conflict. For instance, robustness can involve resilience under heavy load. If an approximate (i.e., incorrect) response to a request can be computed much faster than an exact (correct) response, it's important to know whether the system should deliver an approximate result, or fail delivering ...
35
If possible, may be spend some time to check if this defect can be reproduced by putting some sleep or block in your application code. But do not spend too much time. As this issue is due to multi-theading (and also as you observed), it's occurrence will be rare.
My advice is not to sweat over this too much. Continue your work. Whenever you come across ...
32
If your current spec leaves this undefined, the behaviour is completely arbitrary, there is no "right" or "wrong" definition. So if your QA engineer cannot point you to the exact paragraph in the spec where this behaviour is defined, you can probably deny his request (though it does not seem to be a requirement which needs much effort to implement it). If ...
30
These requirements are not silly, stupid or ridiculous. This is in fact very important problem for users of touch screens, that people with larger fingers have it very difficult to pinpoint the target, which is often not understood by little-fingerers.
However, if you find this requirements impossible to implement because device's sensors are not able to ...
30
The requirement, as stated, is fuzzy to me.
The first question I would have is: how many character encodings need to be supported? Possible interpretations include:
Every encoding ever devised, including single-byte (e.g. ISO-8859-15), multibyte (e.g. Big5, Shift-JIS, HZ), and rare/weird ones (e.g. UTF-7, Punycode, EBCDIC).
That's obviously extreme. How ...
28
This answer will focus on how to work with User Stories and lower level requirements. I won't be discussing the virtues, or lack thereof, of Scrum or Agile. I won't be talking about gurus either.
This answer assumes you're on board with Scrum but haven't yet found a way to make it work for you.
As others have mentioned, User Stories are meant to cover ...
28
However, all agile processes I know strongly favor must-be requirements. These always get the highest priority.
As they should - look at your Kano model again: if the must-be requirements are not satisfied, the customer will not accept the product. And then your delighters don't matter.
There doesn't even seem to be a place for attractive qualities in ...
answered May 20 '17 at 16:48
Michael Borgwardt
45.6k11 gold badges110 silver badges163 bronze badges
27
What I have never done, but I know others do, and it is awful, but apparently it works, is this:
Give them a quote (say, €500) for the simplest possible web site that covers their requirements. (The crummiest thinkable two-story house made of matchsticks.) They will like it, and they will stop talking to your competitors and start talking to you.
As they ...
25
We refer to them as "nice to have" features as opposed to requirements.
23
There are many ways to answer such queries -
Answer 1: It will cost you X Euros per hour to define the system, after which I can give you a fixed price for a set of agreed-upon features.
Answer 2: send them a video clip of sharks in a feeding frenzy, and ask them how long it will take them to count the fish (not just the sharks), given that they can't see ...
23
Short answer:
830-1998 is not a standard, it is a recommended best practice on how to write SRS in the style of 1998.
I can't find how it was superseeded (even with IEEE's advanced search :( )
But I guess it's because the whole method on how we specify requirements has changed drastically in recent years.
So, from now on, I try to answer a bit of ...
22
As I commented, I have a strong feeling that the requirements were not clear the first time or probably you missed some important details.
Not everything can be addressed with better code, best practices, design patterns or OOP principles. None of them will prevent you from redoing the whole application if the implementation is based on false assumptions ...
21
So how can I learn to really do object oriented design? What I want to learn is: given requirements know how to get started working on them in a process that leads to find out what has to be done and where each piece of code belongs. How can I also learn to judge if my idea is correct or not?
Well first of all, stop thinking of object oriented design as ...
20
functional requirements
What the system is supposed to do, process orders, send bills, regulate the temperature etc. etc.
operational requirements
These are about how to run the system. Logging, startup/shutdown controls, monitoring, resource consumption, back up, availability etc.etc.
technical requirements
These are about how the system is built. ...
20
"A bug in requirements" could refer to one or more of the following (more may exists though...):
A requirement provided by the end-user that conflicts with another requirement or constraint. Example: The user wants to email all customers but does not want the system to collect customer emails.
A requirement provided by the user and not flagged by the ...
19
There's absolutely no "Agile" problem with having a fixed release date if you're prepared to move one of the other two edges of the "iron triangle": the requirements for what needs to be in that release, or the resources you have available. You can't fix all three - and in practice, the "resources" side of the triangle is very often either not very flexible ...
18
I see two good possible approaches to to this problem. However, it's important to realize two things. First, requirements engineering is hard work - turning an idea into a formal specification that is enough to build a system takes a lot of time, effort, and practice. Second, if you have good requirements (in any format, from a formal specification to less ...
Only top voted, non community-wiki answers of a minimum length are eligible
