Notesale: Turn your study into money

Document Preview

Extracts from the notes are below, to see the PDF you'll receive please use the links above

---

TABLE OF CONTENT

No
...
0

Executive Summary

1

2
...
0

Introduction

3–4

4
...
1

A General Look at Software Development Life Cycle (SDLC)

5

4
...
3

SDLC Common Objectives

6

4
...
5

SDLC Common Roles & Responsibilities

5
...
0

Software Requirement – What is it?

11 – 13

7
...
0

Overcoming Requirements Modeling Challenges

17 – 19

9
...
0

Conclusion

24

11
...
0 Executive Summary

It has been suggested that there is more than one reason for a software development project to fail
...
Failure can be in various forms
...
Often they are over budget; the anticipated
cost for the project is exceeded by a large factor
...


In this paper, I will only discuss one of the main core reasons for a software development project to
fail and argue it which is the consequence of failure to specify requirements anything like
adequately
...


In this paper, I will present and discuss several requirements risks that may have major impacts on
the success of software projects
...
It concludes with suggested strategies for avoiding and/or mitigating these risks
and associated implications
...
0 Acknowledgments

―I would like to thank my lecturer, Mr
...
Thanks also to all the
people who provide useful suggestions to me in which aid me in researching and compiling the
paper
...
"

2

3
...
Today, there are several software development
methodologies in use and it was written without much of a plan, and the design of the system was
determined from many short term decisions
...
Most especially
large IT projects are those that involve hundreds of software engineers and require many years to
complete often fail
...
Sometimes the delivered system fails to
provide significant requirements to the standard of quality which makes it possible to actually
deploy the system
...

Sometimes the anticipated delivery date is exceeded by a large factor
...


As hardware components are becoming cheaper and powerful day by day, the expected services
from modern software are increasing like any thing
...
Not only the complexity, but also the developing of such software within the
time constraints and budget has become the real challenge
...


On stream, the requirements of the clients are changing so frequently that it has become extremely
tough to manage these changes
...
As a result, nowadays there is none of the
existing models are helpful to cater the modern software crisis
...
The answer is that software projects fail because poor
communication among customers, developers and users which cause failure to specify requirements
anything like adequately — what that is eventually delivered is not either what was originally
3

specified nor what is actually needed
...


That’s why though many organizations today have a very well-defined software project
development process; on the contrary, they have a poorly defined system to manage changes in
requirement specifications
...




Lack of understanding that cost and schedule are engineering parameters based on requirements
...


Therefore, requirements elicitation is a central and critical activity in the systems analysis and
design process as confusion, misunderstanding, and frustration relative to requirements are major
risks to the success of any project
...


In this paper, I will present and discuss several requirements risks that may have major impacts on
the success of software projects and presents a classification of communication challenges that arise
during the requirements elicitation process
...
Lastly, I will then consider strategies to help mitigate the impact of these
requirements risks
...
0 Background

4
...
2 Software Development Life Cycle (SDLC) Overview – How it Evolves

SDLC stands for Systems Development Life Cycle
...
SDLC
Cycle refers to either a descriptive of prescriptive characterization of how software is or should be
developed
...


The SDLC consists of many kinds of software development methodologies
...
Some of these are the waterfalls, fountain and
spiral
...

Among which the original model is the waterfalls
...


The names of the steps may differ but basically it begins with project planning, feasibility study and
initiation
...
It is
also during this stage when funding would be determined as well
...
3 SDLC Common Objectives

An SDLC is developed to disseminate proven practices to system developers, project managers,
program/account analysts and system owners/users throughout any organization
...
To reduce the risk of project failure
...
To consider system and data requirements throughout the entire life of the system
...
To identify technical and management issues early
...
To disclose all life cycle costs to guide business decisions
...
To foster realistic expectations of what the systems will and will not provide
...
To provide information to better balance programmatic, technical, management, and cost aspects
of proposed system development or modification
...
To encourage periodic evaluations to identify systems that is no longer effective
...
To measure progress and status for effective corrective action
...
To support effective resource management and budget planning
...
To consider meeting current and future business requirements
...
4 SDLC Common Phase

In SDLC, Decide Phase covers all those activities involved in deciding what it is that you want to
build
...

(2) System Concept Development – Defines the scope or boundary of the concepts, includes
systems boundary, document, cost benefit analysis, risk management plan and feasibility
study
...

(4) Requirements Analysis – Analyses user needs and develops user requirements create a
detailed functional requirements document
...

(6) Development – Converts a design into a complete information systems includes acquiring
and installing systems environment; creating and testing databases preparing test case
procedures; preparing test files, coding, compiling, refining programs; performing test
readiness review and procurement activities
...

(8) Implementation – Includes implementation preparation, implementation of the system into
production environment, and resolution of problems identified in the integration and test
phase
...

(10) Disposition – Describes end-of-system activities, emphasis is given to proper preparation of
data
...
5 SDLC Common Roles & Responsibilities

According to NYS Project Management Guidebook, in SDLC, the team members have the
following roles & responsibilities:

(a) The Project Team
— It consists of a Project Manager and a variable number of Project Team members who are
responsible for planning and executing the project
...


(b) The Facilitator
— The one who leads sessions to identify business requirements and issues, keeps session’s focused
and productive, draws out issues and ideas from all participants, and maintains clear and open
communications within the session
...


(d) The Database Administrator
—The one who is responsible for providing and maintaining database administration policies and
procedures, approving and executing database scripts, performing database tuning activities, and
transforming a pictorial representation of the system data into physical database tables that support
the final system
...

8

(f)The Technical Lead/Architect
— The one who drives the logical process and data models into application architecture, establishes
architecture guidelines, and develops strategies for the creation and distribution of applications
...


(h)The Software Quality Assurance (SQA) Analyst
— The one who is responsible for establishing and executing the Quality Assurance Plan, for
assisting in the preparation of test scripts and test data, and for participating in integration and
acceptance testing efforts
...


(j)The Information Security Officer (ISO)
— The one who is responsible for identifying and enforcing security standards and processes
...

Support includes the documentation of user, training, operation materials, and help files, training for
Customers, responding to technical and business questions forwarded to the Help Desk, and
supporting the project and associated administrative processes
...
0 Software Project Failed – How is being defined?

Before starts to discuss about true reason why software projects fail, let's define failure first
...




User needs have not been met
...




The product is so late that by the time it is rolled out, the users either no longer need it or
another product has been found to fill the user needs
...




The product is so far over budget, that the project was cancelled
...
Here different organizations
will have different percentages to indicate failure
...
Quite often this will boil down to inaccurate project costing because the
project design was either sloppily done or not done at all because it was easier to just hand it
over to a third party and let worry about it
...
Now go and do
it in Y months!



The project is so complex that no single person can get a complete understanding of how the
whole thing hangs together and when it will be completed and it is already X years overdue
...
0 Software Requirement – What is it?

Requirements must be determined and agreed to by the customers, users, and suppliers of a
software product before the software can be built
...

(2) What the software must be to add value for its stakeholders – These are the nonfunctional
requirements that define the characteristics, properties, or qualities that the software product
must possess
...

(3) What limitations there are on the choices that developers have when implementing the
software – These are external interface definitions and other constraints that define the
limitations
...
‖ However, by recognizing that there
are different levels and types of requirements, as illustrated in Figure 1 adapted from Karl Wiegers
(2004), practitioners gain a better understanding of what information they need to elicit, analyze,
specify, and validate when they define their software requirements
...


User requirements look at the functionality of the software product from the user’s perspective by
defining what the software has to do in order for the users to accomplish their objectives
...


As opposed to the business requirements, business rules are the specific policies, standards,
practices, regulations, and guidelines that define how the users do business (and are therefore
considered user-level requirements)
...


User-level quality attributes are nonfunctional characteristics that define the software product’s
quality
...


A quality attribute may translate into product-level functional requirements for the software that
specify what functionality must exist to meet the nonfunctional attribute
...
This behavior
may be expressed as functions, tasks, or services the system or product is required to perform
...


A quality attribute may also translate into product-level nonfunctional requirements that specify
the characteristics the software must possess in order to meet that attribute
...
Think of these properties as the
characteristics or qualities that make the product attractive, or usable, or fast, or reliable
...


The constraints define any restrictions imposed on the choices that the supplier can make when
designing and developing the software
...


13

7
...


It shows how that all 12 scenarios present ways in which the Project Manager,

Stakeholders, and all involved parties within a Project can be misrepresented and unsuccessfully
managed
...

 The customer usually has no clues what he really needs
...

 And he’ll demand them up front, because he is afraid he
won’t get them added later
...

How the Project Leader Understood  The Project Manager usually gets some critical detail
It

wrong
...

 But, still, the Project Manager failed to understand the
customer’s needs and desires
...

 A common ―fix‖ is to break something else to work with
its existing design
...

 Programmers

implement

things

quite

literally,

sometimes
...


How

the

Business

Consultant  These folks are the engineers’ nightmares
...


How the Project Was Documented

 The project was clearly a blank slate
...


What Operations Installed

 Operations only installed one component
...

 Sometimes we spend months getting certain features to
work, only to find out later that those features were
never installed at the customer site because a) they didn’t
work, b) the installer didn’t understand how it worked,
or c) someone was afraid the fixes were no good
...

 The Project Team gets to charge for all their clueless
machinations
...


How It Was Supported

 The fact of ―Is this feature causing the customer to call
tech support? Perhaps we should remove it
...


What Marketing Advertised

 The marketing people push wastefulness rather than
practicality and reality
...

 It would be so much easier if we could ever get to this
simple starting point
...
Because of this, the goal was either compromised or was a failure
...
0 Overcoming Requirements Modeling Challenges

Consequently, we may have understand that very often requirements modeling efforts are
undermined by the project team environment – it is common to discover that an organization’s
culture isn’t conducive to effective software development efforts or project stakeholders do not
understand the implications of their decisions
...
By so doing, the risk of giving the
stakeholder what they ask for, rather than what they really need, is increased
...
Thus, it is not enough to obtain the stakeholders’ requirements once
and assume that they are correct
...
It is characterized by not involving project stakeholders
throughout the development effort
...

However, typically this requirements risk will not be identified until stakeholder testing or
implementation
...
At this stage of
development, there will almost certainly be negative impacts on both project cost and schedule
...


17

(4) The Expectations Cloud
There are numerous software project examples of stakeholder expectations not being resolved prior
to the project beginning
...


(5) The Never-Ending Requirements Story
The world we live in is rapidly changing
...
In
this environment, it is unrealistic to assume that software requirements are not going to change
during the development process
...


The never-ending requirement story is also one of the never-completing software projects
...
The result is confusion, chaos,
misunderstanding, and software either never being completed, or if completed never being used
...


The risk of allowing this attitude to exist in the stakeholder environment is that valuable
development resources are wasted playing a guessing game causes increases development costs and
extends the project schedule
...
They remain removed from the project, do not accept ownership, and thus increase the
risk of project failure
...
When conducted properly, each of these approaches includes a process of
requirements analysis
...


The risk associated with these approaches is the same old temptation to cut corners when
conducting requirements analysis that we often find in more traditional approaches
...
Some do not recognize the need for adequate requirements analysis and will eliminate
or minimize the requirements analysis process
...


(8) Failure to Recognize that Faulty Requirements Represent a Risk
The soundness of the organization's requirements management process should be taken into
consideration when evaluating the risk that requirements may have on the success of your project
...
Years of experience have
revealed that errors occurring in the requirements stage of the development process turn out to be
the most difficult and costly to fix
...
The need to communicate requirements is directly
connected with the need to document requirements
...
If requirements are not documented in some manner, it is impossible for multiple
individuals to come to a common understanding and agreement of the requirements
...
0 Recommendation — Strategies to Mitigate Requirements Risks

In this paper, I also discuss potential solutions for dealing with those challenges which encompass:

(1) Develop and Follow Sound Processes and Procedures
The problem comes when the process that I follow and the process others in the organization follow
is not the same
...


An important step to mitigating requirements risks is for the organization to develop and strictly
follow sound processes and procedures relative to requirements engineering
...




Requirements analysis
...




Requirements verification, review, and approval
...




Requirements traceability
...


(2) Incorporate Requirements into All Software Life Cycles
By now, the need and value of having organizationally accepted software lifecycle models and
methods should be well established
...
By assuring that the life cycle(s) approved for usage within the organization require proper
levels of requirements administration, the risk associated with projects relative to requirements will
be reduced
...
Those within the organization
who are responsible for assuring that requirements are managed, must receive the training and
mentoring necessary to provide them with the ability to fulfill this responsibility
...
Thus, the need for user involvement is imperative
...


(5) Always Document Requirements
The need to reach a common understanding of requirements among key project stakeholders had
provided the essential that the requirements need be documented
...
Today there are three basic
forms of documentation used for requirements: text based, box based, and graphics based
...

This approach has been criticized as being old fashioned, slow, and subject to various
21

interpretations based on the background of the various stakeholders
...
This approach is designed with the software engineer in mind and is generally more
comfortable for the software engineer to follow and understand
...


Graphic-based documentation is the most recent of the three documentation forms
...
This method uses
geographic symbols to represent the actual objects within a system
...


We recommend that some combination approach be adopted, experience using a combination of
graphics and text
...
It also is easily understood by the developers and serves as a useful tool to both
elicit and validate requirements
...
Requirements validation is
an essential step to ensure that requirements are properly understood and documented
...

This mitigation strategy goes hand in hand with the need for dedicated stakeholder involvement
...
Errors,
inconsistencies, ambiguities, and confusion can be greatly reduced by holding formal reviews of
software requirements documents
...
Teams performing requirements management activities should be trained
in sound review methods
...
" Without sound strategies for managing
change, a project will fail
...
Requirements creep should be
around 1 percent per month
...


For the good of the project, some changes are simply too expensive or too difficult
...
Such changes
must be postponed until after a version of the product is successfully delivered
...
0 Conclusion

Overall, in this paper, I have illustrated and argued that, many of the reasons given for the failure of
software projects is an inadequate respect for the project’s understanding of requirements
...


And finally, while offering no silver bullet, I also have suggested that a true belief in requirements
drift among engineers and their managers may itself go a long way towards mitigating its effects
...
By their very nature, there are risks associated with the elicitation, analysis, and
validation of requirements
...


If not given proper attention, these requirements' risks can push software projects overboard and
result in software projects drowning! On the other hand, instead of requirements being the source of
problems, a disciplined software requirements management process will able to help to assure the
success of a software projects
...
But if this article has helped serve as a reality check for your project,
it will have served its purpose
...


24

11
...
DAVIS ROBERT M
...
BERNDT‖
Available at
http://www
...
edu/faculty/richarme/MARK%205338/Davis%20repertory%20grid
...
cs
...
edu/~sme/papers/1996/NASA-IVV-96-002
...
allaboutagile
...
Ambler
Available at
http://www
...
com/essays/requirementsChallenges
...
quillenit
...
au/docs/Why_Software_Development_Projects_Fail
...
‖
Available at
http://www
...
ny
...
pdf [accessed 1 August 2012]

[PDF] ―Software Requirements Engineering: What, Why, Who, When, and How‖ Linda Westfall
Available at
http://www
...
com/Papers/The_Why_What_Who_When_and_How_Of_Software_Requi
rements

---