56

To be honest, after spending close to two years immersed in Agile development, I still think "user story" is just a fancy term for "functional requirement". It's different at a superficial level, e.g. it always takes a certain form ("as an X, I want Y so that Z..."), but the key elements - identifying the stakeholder and the rationale - are also inherent in ...


33

Requirements don't need to be captured in a formal software requirements specification or any other kind of document. They can be captured in tests (primarily acceptance tests and system tests, but perhaps also integration and unit tests), issues (feature requests, bug reports), discussions (both persistent like mailing lists or ephemeral like chat rooms), ...


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


27

Functional requirements: What the system is supposed to do, process orders, send bills, regulate the temperature etc. etc. Operational requirements: These are about how to run the system. Logging, startup/shutdown controls, monitoring, resource consumption, back up, availability etc.etc. Technical requirements: These are about how the system is built. Which ...


18

It looks like you have churned your way in an uncontrolled development process to create a never-ending development system. This occurs in agile systems too. The root problem is a lack of requirements, and while your solution might seem to be to use an agile methodology to fix this (as agile is designed around changing requirements) it would not solve the ...


17

Some good answers here already, especially for your question where requirements are found in Open Source projects. Let me say something about a reasons, why is it hard to find a formal spec document for such projects. SRSs make most sense in projects with an economical interest between two parties. Some customer / client / employer requires some software and ...


16

Ron Jeffries wrote a long time ago about the 3Cs of user stories (http://xprogramming.com/articles/expcardconversationconfirmation/) with the emphasis on a card (short description), conversation between the customers and the delivery team once a user story becomes actionable, and the agreed confirmation of a story after that conversation. essentially, ...


16

Because not all requirements do change, and not all requirements change in the same ways. You're not going to spend awhile working on software to manage a warehouse, only to suddenly decide to instead re-work the software to schedule dentist appointments. Some requirements do change that have a big impact, like changing what OS it runs on, and sometimes ...


16

Non-functional requirements come in many forms, but they have one thing in common: The don't describe functional behavior of the system but rather put constraints on the design choices that you can make. Non-functional requirements are ill suited to be expressed as user stories because user stories work best when they can be implemented once in a short ...


16

Don't let the software prevent you from seeing the projects. I challenge the idea that you need requirements for a software. And suggest that requirements are for software projects. And that there are many software projects in the making of a software. Of those, only one was the inception, and that one is often the worse documented. Alright, perhaps from a ...


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

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


12

18 months, 150 tables and still not in production? Sounds much like a death march for me. The only way you can fix this, if there is any chance to save this now, is to narrow the scope of your project dramatically - at least for your first production release. What you need is proper release planning, small, reachable goals and getting the system to the end ...


11

Define everything. The only potential negative to doing so is that you may get something back complaining that they feel you're stating the obvious. State the obvious then. This is key: Anything you don't define can get thrown back in your face with "you never told us..." Anything that isn't defined can potentially blow up in your face. "Better safe than ...


11

Why do we spend so much time gathering detailed requirements at the beginning if we know that they will be invalidated and change in the not so distant future? It's time to stop gathering requirements the moment writing and demonstrating code becomes the most effective way to communicate your understanding of the requirements. If you continue gathering ...


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

Because software engineering isn’t done for some abstract pursuit of software engineering, it’s about building a useful result. If halfway through the construction of device A you find out that it won’t be useful, won’t be competitive, has huge unforeseen issues, etc., then you’re better off scrapping it and building device B. The dev effort sunk into A is ...


9

The industry term for such requirements as you describe is called: Non-Functional Requirements They should under every aspect be identified by technical resources and added to the project plan as atomic units of work. If you are doing an Agile project then they would be written in user story form and added to the backlog to be dealt with. As the ...


9

One facet of this; If you have no requirements why are you writing any code at all? Code doesn't exist to please itself. Whatever reason you're writing for has a requirement hidden in it, and the sooner you understand what's actually important, then you can make decisions that set you up for success. You need to know what "done" looks like, otherwise you're ...


8

If you can't manage requirements and don't have people capable of implementing requirements properly, SCRUM isn't going to help you (much), and that seems to be the real problem you're facing. SCRUM can help you better deal with changing requirements than more static project management systems, but it's not the holy grail that will magically make everything ...


7

There may be many stakeholders in the real world, but as far as the developers are concerned, there is only one: The product manager who was selected by the companies involved to have the responsibility that the product created is what the stakeholders need. If that person isn't there or fails to do their job, the project is going to fail. The product ...


7

What you're probably thinking of is Big Design Up Front, and yeah, it's not necessarily the best way to manage a software project. But you still need a clear picture of what you want to accomplish when you undertake a new software development project. Broadly, you need to know what benefits you expect from the new software, how much money it will save, and ...


7

"Non-functional requirements" is a bit vague and open to interpretation. Going on your specific example, I would say that those requirements should be used as acceptance criteria for other stories. If you are concerned about repeating the same non-functional requirements story after story after story, another solution would be to bundle all of these ...


7

This is a rather unusual interpretation of “Working Software over comprehensive documentation” value. This value of Agile manifesto was created as a reaction to the projects where documentation consisted of hundreds or thousands of pages of documentation nobody would care to read; the goal was to replace those huge and hugely useless manuals collecting dust ...


6

User stories and requirements are very different beasts. Requirements Requirements presuppose that the design of the application is done beforehand, and that development is the implementation of that design. Requirements therefore focus on how to implement a functionality. Example of requirement: Build a user contact form with the following fields: name, ...


6

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


6

Considering you are working alone the vision document would be less useful for you than most as it's mostly a communication tool. More importantly however, the vision document is a reference point, something you can look back to and determine whether or not your efforts are going to the right place. Even as a solo developer we can be in two minds about ...


6

One thing that makes software projects special is that once you have fully analyzed everything, you are basically done with the job. Of course you can't afford to do this as long as it is unclear if you will get the job. Therefore it is normally required to take the risk and make a quote with very little knowledge. Often it is possible to compare the ...


6

If you are producing a software requirements specification (SRS), I would expect that both GUI requirements and design constraints would be captured in that document. In ISO/IEC/IEEE 29148-2011, the outline of the sample SRS says that the section for design constraints is used to "specify constraints on the system design imposed by external standards, ...


6

On an OOP conference in Munich, ~20 years ago, I asked one of the speakers (Chris Rupp, author of several books about requirements engineering) which tools she would recommend for collecting requirements. As I remember, she answered "The most frequently used tool in the industry for requirements engineering is MS Word, closely followed by MS Excel"....


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