Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 4

April 29, 2020

SE Assignment

Submitted To :Prof. Hirra Nazeer

Is it possible to assess the quality of software if the customer


keeps changing what is it supposed to do ?

Submitted By:
Gohar Riaz (26)
MSC IT (4th)pre
Software Quality Assurance…. Assignment 2
Ans 1
There’s an old adage in software development:

“Fast, cheap, or good. Pick two.”


The key is to create an environment during upstream work where scope creep is
not an issue during the implementation phase. This is one of the reasons large
government projects gravitate towards a pure waterfall or spiral development
model. In these models, it’s imperative to have a strong, detailed statement of
work, and a requirements document that is signed off by the appropriate parties.

That said, the short answer to your question is yes. In fact, the answer to most
development questions is almost invariably “yes, we can.” The catch is that it will
come with a cost. If you have a flaky customer, make sure you get them to a point
where they feel tangibly that “it hurts when I do that!” If they want to increase
scope, it’s invariably going to increase the length of the QA cycle. Every time they
add a new feature, not only is it going to take longer to implement, it’s also going
to take considerably longer to do a full regression.

That comes with a price tag. Point to their wallet and say, strongly, “give me
more.”

Ans 2
Well, yes. Doesn’t make it easier, but sure it’s possible to assess.

You do it like when you have stable requirements: Pair the requirements off with
the current features of the code.

Nothing changes there, just because the requirements change.

Ans 3
Is there any software can be done without any requirement change? The answer is
no.

Page 1
Software Quality Assurance…. Assignment 2
It’s definitely possible to assess and assure software quality even if requirements
keep changing. You can try to adopt Agile + BDD + Continuous Delivery to
resolve the challenges.

Let’s discuss what all points need to consider


if changing requirements continuously:

 Use of rapid prototyping is best option if possible. So this will help customers
feel sure of their requirements and minimize changes.

 To minimize the effort of regression testing later first prepare for risk analysis
of changes.

 If possible then new requirements should move to the next Phase of the
application. Stick to original requirements in the current Phase.

 Spend adequate time to think of probable changes in initial stages of project.

 Make sure that the code is well documented and commented as well. For
developers this helps to make the code changes easily.

 Prepare for requirements traceability matrix that would help to trace what all
test case needs update if specific requirement is changed.

 Creating automated testing such a way that if changes in requirement then


expected effort is minimum to deal with new changes.

 Generic level test plan should be prepared & more flexible test case should be
design (it is not simple to design flexible test cases). Minimize detailed test
cases writing, you can go with high level test cases if requirement changes
continuously.

 Understand risk involved in ad-hoc testing let’s focus less on comprehensive


test plans and test cases.

 Automation test scripts should be created more flexible & adaptive in nature.

 First concentrate on automation testing piece that probably remains unchanged


after change in requirements.

Page 2
Software Quality Assurance…. Assignment 2

 Make sure that management and client understands the cost, schedules &
impact of changes in requirement and they are acceptable with the changes.

If same issue still exists then figure out why these requirements are not aligned
with realism. You have to re-factor the software development process followed
in your organization.

So follow Agile Development process might be the GOOD option to go with


because it allows you change in requirements in late in Software Development
process as well, it is intended for that. Also the end user or customer
involvement is on all stages, so customer is aware of what is implementing & if
they want to changes in requirement or add new requirement then it can be
easily accommodate.

Page 3

You might also like