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


16

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


15

Requirements will grow and change. I don't think anyone could argue that. How to collect and process incoming requests. In my experience it helps when gathering requirements if there is a single or very small group of customers acting as a filter for delivering new or updated requirements to a small group of development planners. Anyone from their side ...


14

A specification nearly always changes during development for any but the most simple of projects. The reasons are: Development or more likely integration testing of the project uncovers things not noticed when original spec was done - from edge cases to major facets. E.g. developer notices that out-of-order message confirmations might arrive. Real world ...


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


13

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


12

Baby steps. Continue to write the SRS for a while. Then call a meeting and discuss whether they still serve a purpose. Does anyone still read them? Is the time spent on them justified? Is there another intermediate step that would be more lightweight? You never know, you might find that you're wrong. Remember the Agile manifesto, we find more value in ...


11

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


10

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


9

I would say that it depends entirely on the nature of your business and the type of client relations you have. Do you or your client have a pressing pressing "salt at the dinner table" need? Do you or your client often need condiments of other sorts? Do you or your client have a history of needing "just this one thing" and then needing that "just one ...


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


8

Loads to be said about all that. Due to this being Programmers.SE I will ignore the aspect about falling out of favor with some folks and your "baffledness". If you want input on those, I suggest you pay workplace.SE a visit instead. Apart from that, let's look at the technical issues here: You are a developer (I assume here), that tells the QA how to do ...


8

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


7

Prohibiting changes to the spec during development is ideal for the programmer, but it's not realistic in a real-world setting. People will always want to make changes, even when the thing is shipping out the door. It never stops. And some of those people may be signing your paycheck. The more they care, the more they think about it, and therefore the more ...


6

One thing you should definitely consider is that they too may be reacting to lots of time critical requests. Taking your example of "change the text to 10pt, then the next day change it to 12pt", unless you have reason to believe that they are deliberately screwing with you, which it does not seem like they are doing, then think about why are they asking for ...


6

Epics are Placeholders In just about any Agile methodology the concept of Epics would be as much as you should need for a Requirements Specification, place holders is what you need at that level. Those entries will be prioritized constantly, any more detail is wasted effort if the requirement gets low priority for a long time, or never even gets ...


6

One strategy: Consider the SRS ID as just a number, and don't imply any strong notion of consecutive order (The social security number is a reasonable example.) Don't recycle numbers. When an ID in a sequence is deleted, mark it "Deleted", "Deprecated", etc. I prefer to keep the requirement text in the deleted item so that I have a running record of the ...


5

Congratulations! You have ascended from programmer/hacker/coder to software engineer, the advanced level at which architecture is a concern. Many professionals in coding never advance that far and never ask this question, so you should be justifiably proud of yourself. Architecture is precisely what you crave: it is all about observing principles that make ...


5

The short answer is that it is difficult, but not completely impossible to manage changes. You have to realize though that changes always happen and they're most likely new ideas that have never been considered in scope before. Now onto the long answer: there are many different strategies you can consider to manage changes all with pros and cons. Below is ...


5

Perhaps it would be better to say that the specification must not change without a valid change request and process. Requesting a specification change has effects on schedule and cost, so these must be factored into the approval. Given that there is a proper change management process, there is nothing "wrong" about changing specifications, but it is likely ...


5

If you don't have an assumptions section you will just have the unknown assumptions of the programmers while they were coding. You have to constantly make deliberate and unconcious assumptions when you are building something - you might as well have them written down.


5

To me, a critical element of a User Story is that it captures Why and How a user uses the system. It is especially useful because it does not specify much in the way of how the system delivers the required functionality. When UI and Usability testing is needed, the User Story may be the most important document. Sure, you can have selenium verify that ...


5

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

Trying to do TDD out-of-blue on highly complex requirement is never good idea. TDD is meant as long-term approach and commitment. TDD won't make it easy to implement change requests and new features overnight. Also, like Carl said, having answers as "if possible" and "maybe" only shows lack of understanding and commitment from side of management. If you ...


4

One thing to do is to try to be forward looking and design your data structures to be able to handle a change, even if you don't put the algorithms and user interface around it yet. Take your Android multi-user functionality as an example. When designing the single user API, ask yourself if you ever have more than one user, if your design will make it easy ...


4

I would look at this as an iterative process. Step 1 is to gather requirements. Step 2 is to sort them. Step 3 is to prioritize them. Step 4 is the break each down into small enough bits to estimate effort. Step 5 is to coalesce these bits into a global effort bucket (let's say 84 person-days). Step 6 is to map the effort to resources (84 person-days / 2 ...


4

There is no reason that all the conditions have to be one requirement. The system shall sell alcohol only to those older than 18. The system shall require proof of age to sell alcohol. The system Shall not sell alcohol to those with alcohol related problems. These are all perfectly valid requirements, and the system is not valid unless it meets all the ...


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



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