April 29, 2008...10:39 am
Implementation of process in SDLC
Implementation of process in SDLC
As all our previous post is about Software Development Life Cycles, so this is the time to have next few posts is on process implementation in SDLC’s.
Different Phases of SDLC:
- Requirement
- Design & Coding
- Testing
- Implementation
Requirement Management:
A requirement is a “function or characteristic of a system that is necessary…the quantifiable and verifiable behaviors that a system must possess and constraints that a system must work within to satisfy an organization’s objectives and solve a set of problems”.
Similarly, “requirement” has the following definitions [IEEE 90]:
- A condition or capability needed by a user to solve a problem or achieve an objective
- A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents
- A documented representation of a condition or capability as in (1) or (2).
Different authors will present different definitions, but there are clearly nonfunctional requirements as well as functional requirements. Requirements are classified as follows
- Functional requirements
Functional requirements define the fundamental actions that must take place in the software in accepting and processing the inputs and in processing and generating the outputs. These are generally listed, as “shall” statements starting with “The system shall…
These include:
· Validity checks on the inputs
· Exact sequence of operations
· Responses to abnormal situation, including
· Overflow
· Communication facilities
· Error handling and recovery
· Effect of parameters
· Relationship of outputs to inputs, including
· Input/Output sequences
· Formulas for input to output conversion
2. Nonfunctional requirements
In systems engineering and requirements engineering, non-functional requirements are requirements, which specify criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that specify specific behavior or functions. Non-functional requirements are often called qualities of a system. Other terms for non-functional requirements are “constraints”, “quality attributes”, “quality goals” and “quality of service requirements”. Non-functional requirements can be divided into two main categories.
i. Execution qualities, such as security and usability, are observable at run time.
ii. Evolution qualities, such as extensibility and scalability, embody in the static structure of the software system.
Key aspects of the process are:
Requirement Process
a. Requirement Elicitation
This concerned with where software requirements come from and how the software engineer can collect them. It includes requirement sources and elicitation techniques.
Activities
i. Elicit requirements from various individual sources;
ii. Insure that the needs of all users are consistent and feasible; and
iii. Validate that the requirements so derived are an accurate reflection of user
b. Requirement Analysis
The very purpose of the analysis is to identify the requirements in a complete, accurate, consistent, and unambiguous manner.
Activities
i. Detect and resolve conflicts between requirements
ii. Discover the bounds of the software and how it must interact with its environment
iii. Elaborate system requirements to software requirements
c. Requirement Specification
Requirements specification typically refers to the production of a document, or its electronic equivalent, that can be systematically reviewed, evaluated, and approved. For complex systems, particularly those involving substantial non-software components, as many as three different types of documents are produced:
1. System definition,
2. System requirements specification, and
3. Software requirements specification.
Activities
i. Preparation of SRS from the requirements collected
d. Requirement Validation
Requirements validation is concerned with the process of examining the requirements documents to ensure that they are defining the right system (that is, the system that the user expects). It is subdivided into descriptions of the conduct of requirements reviews, prototyping, and model validation and acceptance tests.
Activities
ii. Conduct Review Meetings
iii. Closing Issues identified in the review meeting
iv. Approval & Kick off
e. Changes Request Management
On receive of any change list from the client or stakeholders that has to be discussed and reviewed with the team.
Activities
i. Analysis major and minor changes
ii. Made corrections in the SRS on approval of CCB
iii. Version updated
iv. Moved to production
Leave a Reply