SAD Lesson 2 Notes
Software development phases
1. Requirements Specification
Understanding the usage scenarios and deriving the static domain model
2. Analysis and Design
Assigning responsibilities to objects and specifying detailed dynamics of their interactions
under different usage scenarios
3. Implementation
Encoding the design in a programming language
4. Testing
Individual classes/components (unit testing) and the entire system (integration testing)
5. Operation and Maintenance
Running the system; Fixing bugs and adding new features
Requirements Specification
Terms definition:
Software specification:- the process of understanding and defining what services are required
from the system and identifying the constraints on the system’s operation and development.
Requirements engineering: critical stage of the software process as errors at this stage lead to
later problems in the system design and implementation.
• Functional Requirements - a description of the facility or feature required.
Functional requirements deal with what the system should do or provide for users.
They include description of the required functions, outlines of associated reports or
online queries, and details of data to be held in the system.
• Non-Functional Requirements - a description and, where possible, target values of
associated non-functional requirements. Non-functional requirements detail
constraints, targets or control mechanisms for the new system. They describe how,
how well or to what standard a function should be provided. For example, levels of
required service such as response times; security and access requirements.
Requirement engineering process
1. Feasibility study: feasibility study can be Cleary explained by the statement “don’t fix it
unless you understand it.” The goal of feasibility study is to evaluate alternative system and
to purpose the most feasible and desirable system for development. Feasibility study consists
the following
a) Statement of the problem
b) Summary of findings and recommendations
c) conclusions
There are five types of feasibility study
a) technical feasibility
b) Economic feasibility
c) Motivational feasibility
d) Schedule feasibility
e) Operational feasibility
i. Operational feasibility study tests the operational scope of the software
to be developed. if for example the proposed software has
a high operational feasibility then its estimated that the software
usability will be high.
ii. The technical feasibility study compares the level of
technology available in the software development firm and the level of
technology required for the development of the product. The level of
technology consists of the programming language, the hardware resources
, other software tools etc.
[Link] economic feasibility study evaluate the cost of the
software development against the ultimate income or benefits to be
obtained from the developed system.
There must be scopes for profit after the successful
Completion of the project.
2. Requirements elicitation and Analysis
i. Derive the system requirements through observation of existing systems, discussions
with potential users and procurers, task analysis.
ii. Development of one or more system models and prototypes possible
iii. Help to understand the system to be specified
3. Requirements specification:- Activity of translating the information gathered during the
analysis activity into a document that defines a set of requirements
User requirements: abstract statements of the system requirements for the customer and end-
user of the system
System requirements: more detailed description of the functionality to be provided
4. Requirements validation
i. Checks the requirements for realism, consistency and completeness
ii. Errors are discovered to correct the specification
Structure of a requirements document:
[Link]
Define the expected readership of the document
Describe its version history
A rational for the creation of a new version
A summary of the changes made in each version
[Link]
Describe the need for the system
Describe the system’s functions
Explain how it will work with other systems
Describe how the system fits into the overall business or strategic objectives of
theorganization commissioning the software
[Link]
Define the technical terms used in the document
Should not make assumptions about the experience or expertise of the reader
[Link] requirements definition
Describe the services provided for the user
Non-functional system requirements should also be described
May use natural language, diagrams or other notations that are understandable to customers
Product and process standards should be specified (if applicable)
[Link] architecture
A high-level overview of the anticipated system architecture
Showing the distribution of functions across system modules
Architectural components should be highlighted (that are reused)
[Link] requirements specification
Describe the functional and non-functional requirements in more detail
Optional: further detail to the non-functional requirements
Optional: interfaces to other systems
[Link] models
Include graphical system models showing the relationships between the system components,
the system and its environment
Examples: object models, data-flow models, semantic data models
[Link] evolution
Describe the fundamental assumptions on which the system is based
Any anticipated changes due to hardware evolution, changing user needs etc.
Useful for system designers: may help to avoid design decisions
9. Appendices
Provide detailed, specific information that is related to the application being developed
Example: hardware and database descriptions
Hardware requirements: minimal and optional configurations for the system
10. Database requirements: logical organization of the data used by the system and the
relationships between data
[Link]
A normal alphabetic index
An index of diagrams
An index of functions etc
METHODS USED BY USERS IN COMING UP WITH THEIR REQUIREMENTS
1. kitchen sink strategy:-user throws everything into the requirement definition,
overstatement of needs such as an overabundance of reports. This approach usually reflects
the users lack of experience in the area.
2. smoking strategy:- it sets up a smoke screen by requesting several system features when
only one or two are needed. Requests have to be reduced to one that is realistic, manageable
and achievable.
3. same thing strategy:-This strategy indicates the users laziness, lack of knowledge or both.
An example statement:- give me the same thing but In a better format through the computer.
The analyst has a little chance of succeeding because only the user can fully discover the real
needs and problems.
It is difficult to determine user’s requirements because of the below reasons:
i. System requirements change and user requirements must be modified.
ii. Articulation of requirements is difficult
iii. Heavy user involvement and motivation is difficult.
iv. The pattern of interaction between users and analysts in designing information
requirements is complex.
Methods of gathering requirements
i. Observation
ii. Interviews
iii. questionnaires
1. Observations
Types of observation methods
i. Natural:-occurs in a setting such as the employees place of work
ii. Contrived: is a set up by the observer in a place like a laboratory
iii. Obtrusive: takes place when the respondent knows he/she is being observed.
iv. Unobtrusive:-takes place in a contrived way such as behind a mirror
v. Direct: takes place when the analyst actually observes the subject or the system at
work.
vi. Indirect: the analyst uses mechanical devices such as cameras and video tapes to
capture information.
System development lifecycle
i. Requirements specification:-involves understanding the user requirements and
coming up with the requirements document.
ii. Analysis:- establish the overall architecture of the system, identify required
components of the new system and the relationship between the components
iii. Design and coding: putting together components to come us with the new
system
iv. Testing:-individual components (units) and the entire system (integration testing)
is done for proper functionality.
v. Implementation:- the developed system is encoded in a programming language
vi. Operation and Maintenance:- involves running the system, fixing any more bugs
that were not identified during the testing stage and adding more features in
future.
Requirements
specification
Analysis
Design and coding
Testing
Implementation
Operation and
Maintenance
In systems theory, a system may be described as a soft system or as a hard system
Soft systems are systems that are difficult to define precisely, because the system
depends on the viewpoint of the person describing it. If it is difficult or impossible to
come to agreement on the boundaries of the system and its behavior, then the system is
considered to be soft. All human activity systems are soft systems. For example, a
banking system is a soft system.
Hard systems are well-defined and it is relatively easy to get agreement on where the
boundaries to the system are, and what the purpose of the system is. The key difference
between soft and hard systems is the amount of consensus that can be reached. The
mechanical operation of a car is an example of a hard system.
VALIDATION AND VERIFICATION
Validation is the activity of checking the correct system is being constructed (building
the right system) while verification is the activity of checking the system is being
constructed correctly (building the system right)
