Hot answers tagged

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


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.


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


5

If you're being rigorous in your interpretation of the three levels, an interface declaration as such would go in the middle level, but it would "extend" into the levels above and below, like this: Requirement The ability to export data X into external system Y. Functional spec Data export will go through a REST interface with the ...


5

The key thing to consider here is whether your stories are manageable chunks of work. To be manageable they need to be: Unambiguously defined Fairly easy to estimate Completable within a sprint So, if you find that merging two stories somehow compromises any of the above points, then don't do it. Personally, I prefer working with many small stories as ...


4

The key to writing good requirements is having a clear, unambiguous acceptance test on each individual requirement that is not subject to interpretation, so that you can declare success. From the customer perspective, requirements are good enough when they clearly paint a picture of what the software does, what it looks like, and what business goals it ...


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


4

Contract matters This is a big mistake because the time that I will spend [...] will not be paid Actually, the big mistake is that your contract makes it possible that you spend your time working for free. It doesn't matter if you are solving a bug or learning a technology required for a new project: the customer has to pay for the time you spend. You ...


4

There are typically layers to requirements, especially if the software is complex or when specifying a system that includes both hardware and software elements. Depending on the complexity of the system, you can have any number of layers. I do disagree with your definitions, however. Requirements always address what the system does (functional requirements ...


4

That's one way to do it. Finding and paying a qualified arbitrator to determine that the delivered system meets the requirements of the MSA/SoW can be a problem. Furthermore, it's not unusual for requirements to change during the development process. I've seen escrow services used more often in the context of "contractor regularly deposits source code in ...


3

I have seen a different meaning to the term escrow as it relates to software development and contracting. Developer stores encrypted version of the software's source code with an escrow service. Escrow service periodically tries to contact the developer / contracting company to see if they are still alive / in business and servicing the software product. ...


2

If your site actually has to work/react differently depending on whether it is accessed from a desktop, tablet or smartphone, then those differences must be visible in the requirements and the use-cases. A use-case should not specify that there is a 'login' button in the top-right corner of the screen, but they can specify that a user on a tablet can ...


2

TL;DR They ought to be two separate, but related requirements. The risk in running them as separate requirements is that you'll have duplicated code for the associated UI and underlying services. But the risk in combining them as a single requirement is that the edit path has a slightly different setup to it. A create path would look something like this:...


2

I think that Option A, with separate user stories, would be preferred. User stories are requirements. There are a set of characteristics of a good requirement that tend to be well accepted. Option A ensures that your user stories are cohesive (addresses one and only one thing), atomic (does not contain conjunctions), and more easily verifiable than Option B....


2

User logins are more of a "feature" than a "requirement." If you said "System shall block user from access to [some area of the system] if they are not logged in," or "System shall block user from access to [some area of the system] if they don't have the necessary security credentials," then it would be a functional requirement. Requirements should ...


2

As a business analyst, I would even say the business requirement in your example could be more of a functional requirement as it talks to a solution not a need. To me a Business requirement is meant to be written from a business perspective and should be technology agnostic as much as possible. Depending on the needs of the business, the need could be met ...


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


1

I'm going to share my opinion, based on how my company assign staff to the projects. Obviously, every company has its staff management. First question is: Do I have an architect assigned to my project? If yes, then architect sould give to lead programmer the basics of the strategy. Or design it atleast. When architects are involved into a project, they are ...


1

This seems pretty subjective. Personally I'd put interface descriptions in the Functional spec (because they are "requirements" rather than "decisions"), or in a separate "appendix" document that doesn't sit on this scale at all. But they'd just as easily fit in the Design spec (because they are implementation details). It's hard to answer this — which,...


1

In the terminology the terminology that I'm used to, your uses for the words don't align. However, there may be alternative definitions in use by other organizations. In my experience, there are multiple sources that place requirements on a software product. The customer and users have requirements, which is what I would call "customer requirements". These ...


1

Sure, rapid prototyping can lead to frequent changes on your APIs for a duration of time, but I will expect changes to eventually mature and stabilize after requirements fall into place and you can essentially do an 'API freeze'. If you are making changes to undo past changes, then you may be getting ahead of yourself and straying away from the You Aren't ...


1

Requirements Elicitation: the process through which the customers, buyers, or users of a software system discover, reveal, articulate, and understand their requirements. Requirements analysis: the process of reasoning about the requirements that have been elicited; it involves activities such as examining requirements for conflicts or inconsistencies, ...



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