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.


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


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

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

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

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

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

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

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

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


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

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

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

I started programming in 1999 and I provide software outsourcing services since 2009 as my own business. During this time I participated to over 300 software engineering projects for over 100 customers in different countries. The good news are that the only one company with good specifications I've seen is NASA. The others usually have a specifications ...


2

Yup, its BS. And Scrum is not Agile. I hate the rigidity of so-called agile practitioners who tel you that there is one way of doing agile and that you must follow all the rules laid out in the holy scriptures of whichever 'agile' methodology they use. Its all BS. Agile is about being agile. Agile is about getting stuff done with a minimum of overhead. ...


2

A functional requirement wouldn't state that a new DB table needs to be created so that different layers of your application can relay user input from the UI. And it certainly shouldn't specify the schema of the table. What you have is not a Function Requirement. It may have started off as one but it looks like somebody along the way has suggested some ...


2

Most of our Lean knowledge comes from the work that Deming did at Toyota. There are two main ways in which I look at Lean: Lean Product Development Lean Production. Lean Product Development is the equivalent to designing new cars, and is more like software development than production is. We're busy creating new things, not producing the same old thing ...


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

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



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