296
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 ...
129
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 ...
95
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 ...
64
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 ...
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 ...
49
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 ...
41
Functional requirements define what the system or application will do - specifically in the context of an external interaction (with a user, or with another system).
When placing a new order, the system shall display the total cost and require confirmation from the user. That is a functional requirement; it describes a function of the system.
Refer to ...
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.
37
How can you know you're done, if you don't know what it's supposed to look like when it's done?
Feature creep will catch you. You'll be trying to deliver for a client, and, as completion time rolls around, they're going to discover 10,000 little things that they absolutely have to have.
In order to get paid, in order to get your boss off your back when the ...
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 ...
34
Features are what sales people sell.
Functions are what programmers develop.
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
The short version:
Run.
The somewhat longer version:
If the manager doesn't know how to run a project, and if the senior goes along with it, then you have next to no chance of fixing things.
In order to manage software projects, a manager does need to understand something about software. If managers don't, they need to learn first. What are your ...
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 ...
27
if you want to be just a programmer, then you wait until someone else has figured out what the client needs and then code that
if you want to be a developer, and this is your client, then you take your client's hand and gently walk them through the dense scary forest of possibilities until together you find the happy bunny-filled meadow at the intersection ...
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
I have spent the last 3 months in an exhaustive - and exhausting - requirements-gathering phase of a major project and have learned, above all else, that there is no one-size-fits-all solution. There is no process, no secret, that will work in every case. Requirements analysis is a genuine skill, and just when you think you've finally figured it all out, ...
Only top voted, non community-wiki answers of a minimum length are eligible
