Hot answers tagged

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


14

The requirement that you've written doesn't have the characteristics of a good requirement. Specifically, it's not cohesive, it's not atomic, and it's not unambiguous. Because of the lack of these characteristics, it's also not easily verifiable. Your initial state requirement is: The downloaded file name may contain non-ASCII characters and processing ...


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

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

In Scrum, requirements go in user stories. The product owner is responsible for talking to all of the stakeholders and gathering requirements. There is generally no single requirements document at all, nor any overall project report similar to what you describe. A user story will describe the requirement at the highest level with a single feature with a ...


4

There are a couple of issues with your wording that weaken the requirement: 1) You should express the requirement in positive terms, rather than in terms of what it should not do. How does one test for "not crashing". 2) The phrase "The downloaded file name may contain..." is vague. A suggested alternative wording (purely subjective, of course) might be: ...


4

An "increment" in this context is a small piece of functionality. To build "incrementally" means completing (and potentially releasing) your work in small bits at a time, as opposed to one large release. "Iteration" refers to the (small) cycles of work that you go through to be able to release incrementally. They are related, but not interchangeable, terms.


4

In this context, "increment" or "iteration" refer to making relatively small changes to a program before rebuilding or redeploying it. One of the core ideas of agile is that you want to aim for frequent, rapid iterations. In agile you typically want the program to be buildable and shippable at all times. It may not be terribly useful or feature-complete for ...


3

If we interpret this question in its most general sense, the proposed duplicate question has perhaps the best answer you could ever get: Too often when you try to design for the future, your predictions about future needs turn out to be wrong. It's usually better to refactor when you actually know how the needs have changed than to overdesign your ...


3

Scrum asks for an ordered backlog, not just a prioritized one. MoSCow can help you to do a course grain prioritization, but you need an ordering for a Scrum backlog. You could use MoSCoW to help you define an MVP but you will ultimately need to sort your backlog as Scrum would suggest. Using MoSCoW long term in Scrum doesn't make sense because the scope ...


2

I think the best approach to this would be to first provide a unique identifier to your state transition diagram. This will allow it to be referenced in downstream work. It would also allow your specific requirements to be explicitly linked to the figure, providing traceability between a visual model and a textual requirement, even if they live in the same ...


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

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


2

You don't, because gathering requirements is not the job of the customer. It's up to you to figure out what the customer needs and to translate it into a formal spec. The usual problem is that you often don't know the business domain quite well to determine the actual needs, while your customer doesn't know what is technically doable, and what is not. This ...


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

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


1

I have not read this title, but usually when someone says build software incrementally they're referring to delivering more and more functionality in iterations. There are different approaches to this, but a lot of them mean starting by developing a minimum set of features/functionality, delivering this to the customer, and responding to feedback/refining ...


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

is it right to include system timer performing sms sending in the use case diagram shown below? If not, what should I replace it with.? Actors in use case diagrams don't have to be humans. It may as well be another system or the system itself. I would replace the "system timer" box with an actor labelled "Alerting system" (or whatever your system is ...


1

Natural language processing is able to process human documents and do some interesting things, like judge the "sentiment" of the document or note similarities with other documents in a corpus. There have been a number of attempts to automagically summarize documents. However, the quality of those summaries varies from "Wow! That was pretty good!" to "This ...


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