Project Management Central

Please login or join to subscribe to this thread

Topics: Business Analysis/Requirements Management
Requirements for an existing system
Network:23



I have taken on a new project for a new client. The goal is to replicate a currently developed website and add a few new features to the new website. Changes will not be made to the replicated, original, website.

As part of our test plans, we want to make sure when we import the previously developed code and add the new features, that none of the previously developed work was broken.

I am trying to figure out the best way to go about requirements gathering so they can be used to create our test plans. The QA team said that if all the current requirements were typed up, it would make things easier for them.

What would you do during this requirements gathering process?
Would you type up all the current and new requirements and their acceptance criteria?
Would you only type up the new acceptance criteria in great detail?
Sort By:
Network:106



That can be a a very challenging question, as you are being asked to reverse engineer an existing system with what sounds like little documentation. Trying to modify an existing system without breaking things often requires a keen understanding of how it works today. That is not so hard with simple systems, but with highly integrated systems it's often difficult to know where all the connections are and what you might be breaking elsewhere. You will have to find a balance between too much and not enough in both requirements decomposition to define testing known areas of disruption, and verification testing that includes both new features, and insuring you did not introduce "unknown-unknowns".

I would work very closely with the QA team, and anyone who has detailed knowledge of the existing website architecture to develop a plan together. Good Luck!
...
1 reply by Karrie Dash
Dec 18, 2018 11:55 AM
Karrie Dash
...
Thanks! That is exactly what my current concerns are. I don't want to spend too much unnecessary time gathering requirements, but I know the consequences of having poor requirements as well. Thankfully, the website isn't too complicated and the most complicated section is an area that we will be redeveloping.
Network:23



Dec 18, 2018 11:50 AM
Replying to Keith Novak
...
That can be a a very challenging question, as you are being asked to reverse engineer an existing system with what sounds like little documentation. Trying to modify an existing system without breaking things often requires a keen understanding of how it works today. That is not so hard with simple systems, but with highly integrated systems it's often difficult to know where all the connections are and what you might be breaking elsewhere. You will have to find a balance between too much and not enough in both requirements decomposition to define testing known areas of disruption, and verification testing that includes both new features, and insuring you did not introduce "unknown-unknowns".

I would work very closely with the QA team, and anyone who has detailed knowledge of the existing website architecture to develop a plan together. Good Luck!
Thanks! That is exactly what my current concerns are. I don't want to spend too much unnecessary time gathering requirements, but I know the consequences of having poor requirements as well. Thankfully, the website isn't too complicated and the most complicated section is an area that we will be redeveloping.
Network:1225



My assumption is that test cases don't already exist for the baseline functionality (ideally automated) which could be reused against the new website?

A lot depends on the need for traceability - if you need to prove that from requirements down to executed test cases there may be no easy way out. Otherwise, if all you want to do is verify that there is no regression then the focus on existing functionality could be met purely by creating and executing test cases - first against the existing site and then second against the new one.

Kiron
Network:1714



Project manager is accountable for project requirements, not for product requirements. From product requirements project requirements must be gather. So, you have to find the person that has defined the product as a component of the whole solution. The other component is the project. On the other side, you never gather requirements. You always gather needs/wants/desires/wishes that must be transformed into requirements or, at least, well formed requirements to avoid things like ambiguity. For all that stuff you need to find the right stakeholders first. Here comes an article I wrote and was published by the PMI and the IIBA as "best practices" just with the intention that perhaps it helps you: https://www.projectmanagement.com/blog-pos...th-stakeholders
Network:6492



Agree with Kiron

Please login or join to reply

Content ID:
ADVERTISEMENTS

"I think popular music in this country is one of the few things in the twentieth century that have made giant strides in reverse."

- Bing Crosby

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events