Tag Info

Hot answers tagged

11

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

They're the client. They get to decide what they want and what they don't want. The way you get them to tell you what they don't really need is by attaching time and dollar estimates to the unnecessary features. They will quickly realize which features are really important to them. Before signing a contract with a client involving money, you need to know ...


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

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

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

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

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


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

Having been in your situation on a few occasions, I've found that UML diagrams and the like are not a good way to go. They tend to be overly complex, and much more difficult to communicate about - now your audience not only has to understand what you said in english, they also have to be familiar with UML diagrams and know how to apply them to the work ...


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

Rather than thinking of this customer as 'difficult' which is negative, how about seeing that just they want to be really involved in the process? Perhaps their experience with working with other suppliers has benefited from a close working relationship? Historically, she has been allowed to completely dominate the development process Do you have ...


3

This sounds like your agile system of working with the stakeholder is almost-but-not-quite working. Firstly, imperative user stories (you should give an example) are simply more detailed, so you can generate better tests from it. Taking this example shows that they do work, but are brittle in the face of changing customer requirements. If the customer has ...


3

If you don't have a requirements spec, you don't know what you're supposed to be doing. Requirements come before everything else. Prototyping is a valid way of proving whether something can be done, but this is not part of the requirements, its part of the solution delivery. Sometimes you're given a specification and tasked to writing a solution document to ...


3

SRS is used to put on paper the requirements for the whole project. Prototyping is used to prove that you're on the right path. When you write the SRS, you may not always be sure whether: The feature is feasible, What if, technically, it is feasible, but your team will spend years developing it, because of the constraints of the language, the platform or ...


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


2

Approach 1: Subdivide sections. You've got four sections, each section is thus 25% of the total survey in this model. If you answer a question at the start of section 1 that leads to the path of "skip all the rest of section 1" that then has you 25% done. Within each section, you have some questions and maybe other branching paths. If section 1 has 5 ...


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


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

If you don't know what you are doing, then the last thing you should do is write a requirements spec, as all that will give you is a requirements spec written by someone who doesn't know what they are doing. Maybe someone else knows what they are doing - if so, they should write the spec. If not, you have to learn what needs to be done. And for this it ...



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