Tag Info

Hot answers tagged

98

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 ...


88

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. ...


51

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 ...


34

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 ...


34

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

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 ...


30

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.


28

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 ...


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 ...


26

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.


25

First off, not all requirements are hard requirements, but rather the minimum supported hardware. If someone has less than the minimum, it may run - but not optimally, or it may not run at all. In either case, its not a supported system and the problems you have are your own. The simplest way to get hardware requirements is guess. The developer looks at ...


21

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 ...


20

1.What is your process for gathering requirements from a client? interview, whiteboard, conference call, shop tour, worker observation, staff interviews, meetings, etc. - whatever is appropriate, whatever it takes to understand the real problem, balanced with whatever they're amenable to and will make time for 2.How much time does the requirement gathering ...


20

Development needs a LOT of space. We use VM images as units of configuration management for developer setups. Once you've copied the VM onto your machine you start it, update the source code from the VCS and you're running. No futzing with developer setups. Each VM image is about 20Gb. 4-5 of those. i.e. we generally need 100 to 120Gb Gb Mind you, they ...


20

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, ...


20

Features are what the sales people sell. Functions are what the programmers develop.


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

If you can't get something out of them, write something up and get it approved. It is a lot easier for non-technical people say 'no, I don't like that' than 'this is how you should do it.' Often times what they want and what they tell you are two very different things. Take some time to write up a first draft of the spec with the info you currently know. ...


19

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 ...


17

I've found that the more a customer complains about how urgent their request is, unless they are also a developer in their own right, it's usually a good sign that the request isn't urgent at all. One of my professors in college always used to tell us not to let the urgent interrupt the important. I usually classify requests in this order (YMMV): Issues ...


17

It is better to explain what the customer will get if you follow their requirements as they are written, and suggest that the requirements be rewritten to clarify the customer's true intent. But generally speaking it is the Project Manager's job to interpret the requirements in a way that will adequately fulfill the customer's needs. It is pointless to ...


17

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 ...


17

If you guess what a client wants, you will ... fail. Clients do not typically know what they want. They just know how an existing process works. Many times it is your job to help them bridge the gap from the "old way" to the "new and improved" way that is possible using computer software (or new computer software). Respect what they know, and help them ...


17

Your situation is quite common and when I was developing things for non-technical clients it happened to me all the time. When those people hire you they most often don't know what they really want. They just know they want "something like that" or "something that can help me with this". Part of a job of a competent software developer is to help those ...


15

Write a suite of unit tests for the existing functionality first. When you do your rewrite, you can use this unit test suite to verify that your existing business rules still work in the new application.


15

I use the Cone of Uncertainty Say in a loud booming voice Basically you do the best estimate you can give the information you have. But you also point out that given the vagueness in the specifications that there is a high uncertainty on these estimates (Point management at the site so they can read up on the principle). As you progress towards the target ...


15

There are a couple of different ways I'd suggest approaching this: Job shadowing -> This is basically watching him do his job so that you know what he is doing and what connections are there between the systems and processes he uses to get his job done. This is totally observation from your end where questions may be asked but only to get a general idea ...


15

is it my responsibly to let them know of the any specific hardware requirements which may impact the performance of the project? It is responsibility of a product provider (your company, in this case) to define minimum requirements for the successful product operation. As a responsible person within your company; it might be tech-lead of the project ...


15

Recently, I had the "pleasure" of producing three separate prototype solutions for a problem our company has related to reports and presenting them to my bosses. Each had its share of advantages and disadvantages in terms of development time, performance, scalability (time between start of project and being able to begin producing reports), ability for ...



Only top voted, non community-wiki answers of a minimum length are eligible