Reference no: EM132218762
Question: Depending on the type of project and the SDLC applied, system requirements may be developed differently. For example, many current projects use the Agile SDLC, and build requirements based on user-story format. A user story is essentially a use case that describes how a specific user would interact with a system. An example of a user story tied to a customer using an ATM might be, "As a customer of the bank, I need to be able to access my account from an ATM to understand balances across all of my accounts."
What are the attributes that comprise a quality user story, and why are these attributes necessary? Consider the result of poorly written user stories. Provide an example of what you would consider to be a quality user story. This example can be from experience, from a company you know of, or one that you create.
Post your answers to the discussion forum.
Respond to at least three of your peers. In your response, consider providing another example of a similar user story.
Peer 1: Hello everyone! I never really done Software to say I have the experience.
What are the attributes that comprise a quality user story, and why are these attributes necessary? Consider the result of poorly written user stories. Provide an example of what you would consider to be a quality user story. This example can be from experience, from a company you know of, or one that you create
Examples would be
Reliability requirements of software fails, error detection and strategy for correction
Security one or more requirements protection of your system and its data. Measurement can be expressed in a variety of ways to break into they system.
Legal there may be legal issues involving privacy of information, intellectual property rights.
Example maybe at a health care clinic/hospital can have all these bad attributes when first doing an SDLC but I am sure they have to be top quality hospitals are one of the most confidential besides banks.
Peer 2: "As a SOC analyst, I would like to be able to edit AD user groups so that I can alter user access to assets."
What makes a user story work is its ability to clearly define who the user is, the feature that is required, and the reason for the required feature. In the user story I wrote, "As a SOC analyst" describes the user, or who is wanting the feature. The feature statement,"I would like to be able to edit AD user groups..." details the feature that I would like to see implemented. Finally, the statement,"I can alter user access to assets" describes the reason that I want to have the feature implemented. These attributes are paramount for a thorough understanding of what a user story is asking for, and ambiguous language, such as "could" or "may have", leaves room for interpretational error that could potentially cause a product to not meet a particular business requirement.
Peer 3: User stories are one of the primary development objects for agile project teams. A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it. One of the important attributes with user-stories is that they be written by stakeholders and not developers, this way it keeps them simple enough. Another attribute is that a user story is meant to be short, usually fitting on a sticky note or note card. The language of the customer so that it is clear to both the business and the development team what the customer wants and why he wants it. Another characteristic of a good user story is that it is easily estimated. The estimates do not have to be accurate, but they should be good enough to use the estimate for prioritization. It also has to be testable. If it cannot be tested and its functionality verified, then it becomes difficult to assess whether it can be considered "done'.