Hot answers tagged

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

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


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


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

Non-Functional requirements and Quality Attributes are one and the same The idea behind the name change in recent times is that, these so called non-functional requirements are in fact system functionality (or a set of system functionality) that has a cross-cut impact in the system. Meaning, the transversal impact that this kind of "special functionality" ...


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


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


1

Generally, the product owner would create a new story that describe new requirements and you would estimate and prioritize the new story as any other story.


1

I will say that it's not limited to functional programming, it's more related to the goal of the project. By using predicate logic (higher order logic) you can create prove for the logic used in the requirement. Translating the logic into functional languages is probably easier. It's also possible to then translate the proven functional language ...



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