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

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


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


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

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

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


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

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

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

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

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


2

This is not fully baked, but you should get the idea. Requirements Table: RequirementID PK Question String Action String Artifact String Condition String Role String Template String Example tuple: Question "What is the minimum age requirement" Action "display an error ...


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

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

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

Many agile experts recommend starting new projects by thinking about what they call the "Minimal Viable Product". What this means is we stop thinking about all of the features an application should have, and instead ask "what is the smallest possible thing I can build that would be useful". Given your example above, I would suggest starting by forgetting any ...



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