Hot answers tagged requirements-management
10
How do I convince my team that a requirements specification is unnecessary if we adopt user-stories?
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 ...
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 ...
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 ...
6
How do I convince my team that a requirements specification is unnecessary if we adopt user-stories?
Epics are Placeholders
In just about an 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 implemented. ...
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
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 ...
4
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 ...
4
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 ...
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
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 ...
3
Requirements are that and only that: what is the required outcome for the system in question?
In this case, the System Requirements appears to be:
Application A must be able to:
install a new service of type 1, 2, or 3
change the service type of an existing service of type 1, 2, or 3
disconnect a service of type 1, 2, or 3
in ...
3
The effect on contributing systems is irrelevant at the level of a user story. The user does not care how it works.
As a [user role], I want [something] so that [benefit]
Ex: As a [mobile phone customer], I want [buy a phone] so that [I can make phone calls].
Note the total absence of any mention for the need to build cell towers ;)
3
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 ...
3
It is hard to tell what metrics to collect for an unknown project with unknown goals. I would strongly recommend you to take a look at some kind of goal definition approach (such as GQM). Using this methodology you might come with metrics that best suit your needs.
Basically, GQM (goal, question, metric) defines a process where: you first define your ...
3
User Stories capture the need of a user to be able to do something, the details of which will be elaborated on during the iteration in which a team takes on that story. That is, a User Story is the basis for a discussion--it is not "Requirements" as such.
So, system requirements should come up in that discussion that occurs during the iteration.
Note that ...
3
"Product Owner" is a term from Scrum, which is only one form of Agile. Scrum is really designed around the notion of small teams of seven plus or minus two, who do all the development and testing of the project solution. The Team would work with a Product Owner, who owns what goes into the project and what does not.
To scale Scrum, organizations have ...
3
As described, it sounds like a design decision, not a system requirement. I think the requirement should sound like this: "The marklar depends on the user's state of residence. For users in NY, NJ ... . For users in WA, ... etc." or "The marklar depends on the user's state of residence, and is calculated according to the following table: ..."
3
Assumption is a strong word. You definitely do want an assumptions section. But you also definitely do want that section to be validated for accuracy.
If, for example, you are designing an app with the assumption that all of its users will be power users, then it had better be true.
So basically, call it what you want (assumptions, prerequisites, ...
2
It depends.
Is the manager a control freak?
Is the manager also a programmer?
Programmers working under you, in general, shouldn't take a stroll into uncharted zones without first discussing the matter with you.
Then, you, the manager, could be utterly incompetent and unable to discern the matter at hand, thus pushing your un-managed programmer to do ...
2
There rarely is a single "Requirements Analyst" position. This is mostly done by either "Business Analysts" or in more Agile processes by the Developers.
Requirements Analysis usually takes place after Requirements Elicitation or Gathering. It means structuring and checking the "raw" list of requirements. It can also mean scoping and cutting down the list. ...
2
Jumping off of David's post: Are you looking to develop a general EHR product or do you have a specific client site installation? We are developing an in-house Oncology EHR system and I don't even know where this project would be without being in the office everyday. If you really want to learn a practice, you really need lots of face-time and time where ...
2
We are using the Bugzilla/Testopia package. You can link specific Test Cases in Testopia back to specific Bugzilla entries. This gives you ability to trace the resolution of a bug (or feature) to a specific Test Case.
The Testopia feature set is decent for managing Test Runs. We use it to track running full regression tests (manual QA) on various products. ...
2
How long you spend developing requirements. This is to see if the overhead is worth the benefit.
Average time to implement a requirement (requirements per hour or day). Some tasks are unavoidably complex, but in general, better-defined requirements don't take as long to implement.
How often requirements change between requirements development and the end ...
2
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 ...
2
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 ...
2
You could phrase it as a tree. This avoids any sort of grouping ambiguity in natural language.
Alcohol can be sold if the buyer meets all of the criteria
Buyer is older than 18 years.
Buyer has the necessary proof of age.
Buyer does not have any alcohol related problems.
This approach also works well for or(One of the following), and nested items.
2
Correct, you'll want to start with a single requirement like:
System must have the capability to register user information based upon geographical state
As that phrasing avoids the particulars about how the information is supposed to be registered.
It also allows the generation of a main service InitialRegistration() that pulls common information for all ...
Only top voted, non community-wiki answers of a minimum length are eligible
