Tag Info

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


26

This answer will focus on how to work with User Stories and lower level requirements. I won't be discussing the virtues, or lack thereof, of Scrum or Agile. I won't be talking about gurus either. This answer assumes you're on board with Scrum but haven't yet found a way to make it work for you. As others have mentioned, User Stories are meant to cover ...


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


12

Answering your questions in order: The mindset going into this in terms of preparation, is to ask the right questions so that the user knows exactly what they want. This is much more difficult than it seems. I need to emphasize asking the right questions. Be specific, if there is any ambiguity, ask another question. Usually during these meetings one answer ...


10

Use-cases are the description of the problem to solve, therefore, they must come before any other step in the process. I'd argue that it's not possible to make anything meaningful without knowing the problem. Use-cases will then determine what you design, whether you make class diagrams before writing any code, however, is personal preference.


9

This seems to me to be the unspoken elephant in the room with Agile projects: how do you prevent them from evolving into chaos? Let's look at the Agile Manifesto for a moment. Agile desires: Early and continuous delivery Embracing changing requirements Delivering working software frequently Developers and business stakeholders working together daily ...


6

Forget a moment about the "BDD buzzword", and let's talk about what we called it the last decades: functional specs. If you think the specs you get from your PO are not detailed enough, write the missing parts on your own. This gives you lots of room for creative discussion, before actually starting to code, but will also help you to remember what decisions ...


6

It sounds as if your problem isn't one of unclear requirements but instead of a missing role that you need on your team. What you need is a Product Owner. Communication is a main function of the product owner. The ability to convey priorities and empathize with team members and stakeholders are vital to steer the project in the right direction. Product ...


5

To my understanding, Lean development intends to optimize the development process of your team, with the focus on balancing between quality, costs and time. It is an organizational method, which does not embrace a specific syntax, language or notation. BDD, however, has its focus on "building the right software", and getting the requirements right, by using ...


4

All examples here are picking on IE 6. Feel free to mentally swap it with Gingerbread or whatever software you are dealing with when reading this. The larger the set of systems that you need to deal with, the more development and testing it will take. This includes resources like actualizing having a machine that still runs IE 6 (for those holdouts). As ...


4

I'll speak to your examples. The first example of a "user requirement" is more like a wish or "feature." The way you can tell the difference between a feature and a requirement is that there's enough detail in the requirement to make it testable. Requirement 1 is not testable because, well, it's a wish. "I wish that the system had some reports for the ...


4

In the context of requirements engineering, the concept of a "system requirement" is referring to a level of decomposition. In a sufficiently complex system, you could have any number of components (where a component could be hardware or software elements). Each component would have its own requirements, usually derived from the system requirements, that can ...


4

You "forgot" to mention it, but I assume you are talking about gathering requirements for a new software by using UML, right? I think the first step in this should always be to understand the use cases (and I am not talking about fancy use case diagram, I am talking about the business process of your users, what they are doing and how the new software ...


4

How old is your app? Almost two years ago I inherited a similar situation in a 5 years old app and we keep calm and carry on, small, small continuous improvements. If I could, I would start from the client and the final user. I'd be gathering requirements in the same way as a new project. It's likely the user / client needs have changed or they have new ...


4

Users most times know exactly their daily work and which problems they have to solve. What they typically don't know is a) how the software exactly has to look like to support that process. b) how they can explain their process to you. So focus on questions to understand what the user really want (their goals, their working process), and not if a button ...


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


3

Remember the definition of an actor: an entity that interacts with your system. The librarian is the one who is actually interacting with the system (the library), whereas the member is just requesting the librarian for a book, and does not care where the hell that book comes from. Then the member is an actor on the librarian, who is a system in herself. ...


3

This absolutely depends on your individual needs and your audience. If you're targeting a largely well-off audience, you can write off old versions pretty freely. If your audience includes a lot of people with older equipment (lower income people, older people, people in the developing world, etc.) you may still find you need to support IE 7 on Windows XP in ...


3

Your question has a lot of layers to it which make a simple answer elusive. At first blush the answer seems obvious - of course all stakeholders should have visibility into the requirements. But what does that actually mean? To answer this please let me summarize your question to make sure I understand the situation correctly. According to your description ...


3

There must be a process of winnowing down customers' desires into what are the actual requirements. Someone has to separate the "nice to haves" from the "must haves", so the team knows what to implement and test. But I would think that sharing the bigger picture would be helpful, because the devs might have insight that would make the functionality more ...


3

What I try to emphasize when doing requirements gathering is that if this is for replacement for an existing system, to not think of how you do things in the existing system but rather what would be the ideal way to accomplish what you need to do. So often users are stuck with the way things are done they can only describe their needs in that manner. The ...


3

Just don't call this a User Story and everyone will be happy. I think the answer is, you can write this down wherever you want. In general, specific implementations are not included in a user story for a few reasons: You know what the customer wants, but you don't know how it is going to be implemented. The customer is aware there are more specific ...


3

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


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


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


2

What database capabilities are needed depends on the application. There are applications which only read data but don't write any. There are applications which only write data, while the reading is done by another application. There are applications which read and insert data, but must by specification be unable to ever update or delete any data, ...


2

Agile. If you cannot agree a full set of specification up-front (and you should be able to at least get agreement on the intended product even if many details are missed) then you have to try the "other way", and build a continually improving prototype that the customer can see, verify and update as they realise what their needs were all along. Asking how ...


2

This question is way too broad to have a definitive answer. Business Analysts make whole careers from this. But to give you an extremely basic answer ... Listen to their ideas. Be humble. You've got to understand why they want this thing. What do they think it will do for them? What problem are they solving? It can be like many questions here: they are ...


2

Option one seems fine if you provide some sort of configuration setting somewhere in the system so that you can change the Email addresses. Option two seems like overkill for what appears to be a relatively straightforward business requirement. Only implement it if it appears that it will solve more problems than just this specific requirement.


2

Two ways: By using well-defined interfaces between the connected systems having clear, unambiguous and documented behaviors, and By writing unit tests that codify behavior at the class and method level, integration tests that verify functionality across multiple systems, and acceptance tests that validate successful fulfillment of the software ...



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