UNIT-II Software Requirement Analysis And Specification:
Need for SRS, Problem Analysis, Requirements Specification.
Software Design: Design objectives and principles. Module level concepts, Coupling and Cohesion. Design Notations and specifications. Structured Design Methodology, Object Oriented Design. Detailed Design: Detailed Design, Verification (Design Walkthroughs, Critical Design Review, Consistency Checkers), Metrics.
The SDD shows how the software system will be structured to satisfy the requirements identified in the SRS. It is basically the translation of requirements into a description of the software structure, software components, interfaces, and data necessary for the implementation phase. Hence, SDD becomes the blue print for the implementation activity.
Purpose of an SDD
Different Verification Methods Used for Detailed Design
✓ Design Verification is a method to confirm if the output
of a designed software product meets the input specifications by examining and providing evidence.
✓ The goal of the design verification process
during software development is ensuring that the designed software product is the same as specified.
The three verification methods we consider are design walkthrough, critical design review, and consistency checkers.
✓ A design walkthrough is a manual method of verification.
✓ The definition and use of walkthroughs change from organization to organization.
✓ A design walkthrough is done in an informal meeting
called by the designer or the leader of the designer’s group.
✓ The walkthrough group is usually small and contains,
along with designer, the group and/or another designer of the group.
1. DESIGN WALKTHROUGH
1. DESIGN WALKTHROUGH
✓ Design walkthroughs provide designers with a way
to identify and assess early on whether the proposed design meets the requirements and addresses the project's goal.
✓ A design walkthrough is a quality practice that allows designers to obtain an early validation of design decisions.
The following guidelines to plan, conduct, and participate in design walkthroughs and increase their effectiveness.
1. Plan for a Design Walkthrough: A design walkthrough should be scheduled when detailing the micro-level tasks of a project.
2. Get the Right Participants: It is important to invite the right participants to a design walkthrough. The reviewers/experts should have the appropriate skills and knowledge to make the walkthrough meaningful for all.
3. Understand Key Roles and Responsibilities: All participants in the design walkthrough should clearly understand their role and responsibilities so that they can consistently practice effective and efficient reviews.
4. Prepare for a Design Walkthrough: Besides planning, all participants need to prepare for the design walkthrough. If all participants are adequately prepared as per their responsibilities, the design walkthrough is likely to be more effective.
5. Use a Well-Structured Process: A design walkthrough should follow a well-structured, documented process. This process should help to define the key purpose of the walkthrough and should provide systematic practices and rules of conduct that can help participants.
6. Review and Critique the Product, Not the Designer:
The design walkthrough should be used as a means to review and critique the product, not the person who created the design.
7. Review, Do Not Solve Problems: A design walkthrough has only one purpose, to find defects. A moderator needs to prevent this from happening and ensure that the walkthrough focuses on the defects or weaknesses rather than identifying fixes or resolutions.
✓ A Critical Design Review (CDR) is a multi-disciplined
technical review to ensure that a system can proceed into construction, demonstration, and test and can meet stated performance requirements within cost, schedule, and risk.
✓ The Critical Design Review (CDR) closes the critical design phase of the project.
✓ A CDR must be held and signed off before design freeze
and before any significant production begins. The design at CDR should be complete and comprehensive.
2. Critical Design Review
A CDR should:
✓ Determine that detail design of the configuration item
under review satisfies cost (for cost type contracts), schedule, and performance requirements.
✓ Establish detail design compatibility among the
configuration item and other items of equipment, facilities, computer software and personnel.
✓ Assess configuration item risk areas (on a technical, cost, and schedule basis).
✓ Review preliminary hardware product specifications.
✓ Determine the acceptability of the detailed design,
performance, and test characteristics of the design solution, and on the adequacy of the operation and support documents.
Completion of CDR should provide
✓ An system initial Product Baseline.
✓ An updated risk assessment.
✓ An updated Cost Analysis Requirements Description (CARD) based on the system product baseline,
✓ An updated program development schedule including construction, test and evaluation, and software coding etc.
✓ Design reviews and walkthrough are manual
processes; the people involved in the review and walkthrough determine the error in the design .
✓ If the design is specified in PDL or some other
formally defined design language, it is possible to detect some design defects by using consistency checkers.
3. Consistency checkers.
✓ Consistency checkers are essentially compilers that take as
input the design specified in a design language (PDL).
Clearly, they cannot produce executable code because the inner syntax of PDL (program design language) allows natural language and many activities are specified in the natural language.
✓ A consistency checker can ensure that any modules invoke or used by a given module actually exist in the design or not.
✓ It can also check that whether the interface used by the calling module is consistent with the interface definition of the called module or not.
STRUCTURED ANALYSIS
OBJECT-ORIENTED ANALYSIS
1. The main focus is on process and procedures of system.
1. The main focus in on data structure and real-world objects that are important.
2. It uses System Development Life Cycle (SDLC) methodology for different purposes like planning, analyzing, designing, implementing, and supporting an information system.
2. It uses Incremental or Iterative methodology to refine and extend our design.
3. It is suitable for well-defined projects with stable user requirements.
3. It is suitable for large projects with changing user requirements.
4. Risk while using this analysis technique is high and reusability is also low.
4. Risk while using this analysis technique is low and reusability is also high.
STRUCTURED ANALYSIS
OBJECT-ORIENTED ANALYSIS
5. Structuring requirements include DFDs (Data Flow Diagram), Structured English, ER (Entity Relationship) diagram, CFD (Control Flow Diagram), Data Dictionary, Decision table/tree, State transition diagram.
5. Requirement engineering includes Use case model (find Use cases, Flow of events, Activity Diagram), the Object model (find Classes and class relations, Object interaction, Object to ER mapping), State chart Diagram, and deployment diagram.
6. This technique is old and is not preferred usually.
6. This technique is new and is mostly preferred.
