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.


8

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


7

You bring up an interesting point, as I don't see that many requirements documents would contain things like: The application shall be free of SQL Injection vulnerabilities, or The application shall be free of CSRF vulnerabilities, as such a list might actually be (more or less) unbounded, and securing credit card numbers with HTTPS is an implementation ...


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

The goal is to (1) deliver a system that satisfies the customer and (2) ensure the people using the requirements have everything they need. Provide the minimal detail level that performs both and you have answered your question. More specifically, does your organization have any requirements standards? I assume not from your question but common templates or ...


5

I'm going to rely upon the SWEBOK (Software Engineering Book Of Knowledge) to guide my answer. In the Software Requirements* chapter, we're provided with more formal definitions of the terms needed for your question. Functional requirements describe the functions that the software is to execute; for example, formatting some text or modulating a signal. ...


4

I've been making my living from this kind of client since the late 1970s, so I can tell you it can be done. At that time of course most businesses weren't automated and so you pretty much had to smoke out your requirements. One client I had recently had issues with the technical dimensions - getting database accounts, server passwords, etc. I would get ...


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

Passing acceptance testing is an indication that the system meets the users' requirements acceptably. As such, the requirements document is generally considered the source of truth for acceptance criteria. There will almost always be further elaboration of requirements during design. If these are truly an expansion of scope, the requirements document ...


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


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

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

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

The acceptance criteria defines when the application is finished. Or to put it another way, when you can ship it. It includes list of requirements that it has to fulfill. This means that some requirements (usually "nice to have" requirements) may fall off, and be implemented in next version. To expand it even further (taken from here) : Microsoft Press ...


3

System acceptance should be against the customer's requirements. You are correct that analysis and derivation is performed against the customer's initial set of requirements. Often, customer requirements aren't enough to design and implement against, so it's necessary to elaborate on the needs of the customer, refine their requirements, and produce technical ...


3

Requirements are what you're supposed to do. Acceptance Criteria are the agreed upon measures to prove you've done them.


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

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

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


2

It's often a matter of timing Requirement are ahead of time. Acceptance criteria are at the software delivery point. This is as others have answered... There is a deeper issue though and perhaps you are seeing it: In an 'ideal' world these would just match. However in the real world a lot happens between these two events, often including some of the ...


2

Yes, this is clearly a requirement for any modern website to do business. Is it from the customer? Maybe, maybe not. Customers surely want you to prevent their credit card data from being stolen, but there are certainly user stories used to represent technical debt and other infrastructure necessities like this. Also I hate to see how the credit card data ...


2

This is essentially a contract dispute, and should be covered in the contract. Would a builder start building a house without knowing how many bedrooms and what the budget was? What would a builder do - he would help the customer by drawing up some plans, agree to the plans, then start building. Would he charge for those plans - that depends, but he would ...


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

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

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



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