Tag Info

Hot answers tagged

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


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

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

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

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


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

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

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

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

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


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


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

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


1

A use case describes an independent, complete interaction done by the user. Think about what the user will be doing. A use case is descriptive. It describes the motivation of the user, what purpose the feature serves, why the feature is important, etc. It does not have the "hard" functional requirements used in a PRD. But it describes the same scenario with ...


1

This is all part of the inefficiencies, inconveniences and potential for errors that are ad hoc requests. These are all compounded the further away from the data the requester is. Good luck with the "big picture" people. Early on, I don't see how you're going to avoid this, but as the same person makes other requests and the more requests you get in ...



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