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

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


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


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

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


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

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


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

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

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

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

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


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

I like Option 2. But then you must treat the back end service as a separate system, with its own use cases, requirements, stakeholders etc. This is probably a good idea if you think you may need to support other front ends such as iPhone and Andriod apps or even a Windows Desktop at some future time.


1

While the question, as posed, has broad scope, the core issues seem to be: ...Scrum assumes that there is no 'requirements freeze'... ...embedded system due to tight coupling with hardware need upfront specification... Scrum aims to produce high quality increments of a deliverable solution. It does not aim to minimise re-work or minimize time to ...


1

Does the software team has any influence on the hardware specs? Or is it purely the other way around (hardware team dictates low-level software interface)? In the latter case, a HAL (hardware abstraction layer) person must sit with hardware team to write the low-level software interface; GUI team can work at their own pace, possibly using Scrum or any ...


1

I don't have personal direct experience in embedded systems - but I do understand waterfall and agile and the differences between the two, as I am sure you do too. I have also discussed this issue - of applying Agile in industries such as embedded software development, semiconductor design/ development, etc. with friends who work in those industries - so ...


1

Scrum is not concerned with requirements freezing or not. Scrum works equally well if you start with 100 stories in your backlog that never change, or 5 stories with more being added/changed all the time. Scrum is supposed to be an iterative process and it requires a totally different mindset than more traditional waterfall models. Technically with Scrum ...


1

If you are faced with the work needing to be re-done, you re-do it. Re-doing the implementation of a product backlog item does not necessarily require any user story to be re-written. The motivation to re-do the implementation may not have had anything to do with a change in the user story. Re-doing some implementation also does not necessarily require a ...



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