The NFR’s and technical requirements should be part of the user story. These can be added as constraints to the story or along with the definition of “done”. Most of these NFR’s can be tested with unit test framework or automated test scripts. Sometimes the process cannot be tested directly. Suppose software requires triple encryption of bank transactions or such things then it will be very difficult to check the state in between. You will have to test the results to verify the process. The ticket generation or the account balance after the transaction will give a correct picture. Performance testing can be integrated with Continuous integrations build or nightly builds.
Traditionally user stories (or requirements) were written by Business analysts. They used to prepare big documents after months of study. It was a herculean task. I used to get such UI/Functional specification documents. I have fixed a lot of bugs because I missed few text in such 1000 + pages document. This is not the only interesting part. Some of the requirements were so weird that I often wondered why I am creating the features which no one is going to use. If I had the option I would have recommended a better option. If the BA’s misunderstood some requirements & customers failed to correct those few words in the epic requirement then we will have a nice situation.
In the agile world the story is different. Product Owners are primarily responsible for user stories. But can anyone else also contribute? Yes. Definitely yes In actual environment many users write user stories. The first requirement may come from end user. The PO, tech architect, scrum master, BA’s... anyone can upd…
In the agile world the story is different. Product Owners are primarily responsible for user stories. But can anyone else also contribute? Yes. Definitely yes In actual environment many users write user stories. The first requirement may come from end user. The PO, tech architect, scrum master, BA’s... anyone can upd…
Comments