SDLC

Requirement Analysis

What is Requirement Analysis

Requirements analysis is the process of determining user expectations for a new or modified product. The success and failure of a software project is mostly depending on requirement analysis stage. The requirements should be documented, actionable, measurable, testable, traceable, related to identified business needs or opportunities.

Requirements gathering problem

Customers don't (really) know what they want• Ensure to spend sufficient time• Make visible any assumptions• Make your customer read, think and sign off the requirements

Requirements change during the course of the project• Have a clear defined process for receiving any change requests• Set milestones for each development phase beyond which certain changes are

not permissible.• Ensure that change requests and approvals are clearly communicated to all

stakeholders

Requirements Gathering Problem

Customers have unreasonable timelines

• Convert the software requirements into a project plan.

• Ensure that the project plan considers available resource

Communication gaps exist between customers, engineers and project managers

• Take notes at every meeting and distribute these throughout the team members.

Fact Finding TechniquesInterview: • In this techniques analyst sits face to face with the

people and record their responses. • Besides analyst can ask the people about their current

problem and their requirement from postposed system. • Remember to follow the bellow rules while conducting

interview:• Determine the people to interview.• Establish objectives for the interview.• Develop interview questions.• Prepare for the interview.• Conduct the interview.• Document the interview.• Evaluate the interview

Fact Finding TechniquesQuestionnaire:

• The questionnaire consists of series of questions framed together in logical manner. The questions should simple, clear and to the point. Questions can be of two types:

Free-format questions: In these types of questionnaires, users are allowed to answer questions freely without immediate response. Examples are:• Is this feature a process?• When will this feature be used?• Who will deliver the inputs for the feature?• Who will receive the outputs of the feature?• What is the end result of doing this?

Fixed-format questions: - It’s a predefined fixed-format questionnaires- Users are allowed to choose the result from the given

answers- Question includes multiple-choice questions (Yes or No

type), rating questions (Strongly agree, Agree, Disagree, Strongly disagree), ranking questions

- Examples are:- Do you feel that the reports are useful? Ο Yes Ο No- Are the reports are useful for your jobs? Ο Yes Ο No- If your answer is No, please explain WHY. Ο Yes Ο No

Fact Finding Techniques• Form to collect requirements for Analysts

Fact Finding TechniquesObservation:• In this technique analyst visits

the organization • observe and understand the

working of the existing system

User Story• description consisting of one or more sentences• Use natural language in description• The typical user story should follow the bellow template:

“As a <type of user>, I want <some goal> so that <some reason>”.

The user stories are useful to express three important questions:• Who are we building it for, who the user is? — As a <type

of user>• What are we building, what is the intention? — I want

<some goal or objective >• Why are we building it, what value it brings for the user? —

So that <benefit, value>

Fact Finding TechniquesBrainstorming:• A technique to generate new ideas and

find the solutions to a specific issue• It is conducted with several team

members and stakeholders• Members from different departments

and domain experts are included to form this team.• The team should then discuss the

problem and comes out with a solution in combine

Document Analysis:• It involves analyzing and gathering

information from existing documents and other related information. • It includes analyzing documents in

the form of design documents, templates and manuals of existing systems. • This technique is adapted when

existing system needs to be replaced or enhanced

Traceability Matrix (TM)• It’s a table used to trace requirements• Each requirement in the RTM document is linked with its associated test case

so that testing can be done as per the mentioned requirements.• Bug ID is also included and linked with its associated requirements and test

case.

• The main goals for this matrix are: Make sure the software is developed as per the mentioned

requirements. Helps in finding the root cause of any bug. Helps in tracing the developed documents during different phases of

SDLC.

Traceability Matrix (TM)

Requirement Specification (SRS)

What is SRS• Completely describes what the proposed software should do without

describing how software will do it.• It is usually signed off at the end of requirements engineering phase.• Software designer will take SRS to design software to specify how the

software will do it

Qualities of SRS• Correct• Unambiguous• Complete• Consistent• Ranked for importance and/or stability• Verifiable• Modifiable• Traceable

Scope• Identify the software product(s) to be produced by name• Explain what the software product(s) will, and, if necessary, will not

do• Describe the application of the software being specified, including

relevant benefits, objectives, and goals

References• Provide a complete list of all documents referenced elsewhere in the

SRS• Identify each document by title, report number (if applicable), date,

and publishing organization• Specify the sources from which the references can be obtained.

Problem Domain• A Context Diagram for depicting

the current system under consideration as a single high-level process• It shows the relationships between

system and external entities• A Context Diagram provides no

information about the timing, sequencing, or synchronization of processes (which processes occur in sequence or in parallel).

Current System Description• This section contains a set of use cases that should describe the

current system behaviors. • A typical use case includes these sections, usually laid out in a table:

Use Case Element Description

Use Case Number ID to represent your use case

Use Case Name The name of your use case, keep it short and sweet

Use Case Description Elaborate more on the name, in paragraph form.

Primary Actor Who is the main actor that this use case represents

Precondition What preconditions must be met before this use case can start

Post condition The state of the software after the basic course of events is complete

Trigger What event triggers this use case

Proposed System RequirementsFunctional Requirements: • define the internal workings of

the software like the calculations, technical details, data manipulation and processing.• Each functionality should

describe with Use Case diagram with detail description.• The behavior that is to be

implemented should be described in plain English

Non-Functional Requirements:• include the requirements

concerning software design or implementation • Performance – for example

Response Time• Reliability• Maintainability• Security• Data Integrity• Usability

Constraints• Tools to be used• Software interface• Hardware interface• Development constraints• Development environments• Deployment environments

Software System Design

What is Software Design

• Software design is a process to transform user requirements into some suitable form, which helps the programmer in software coding and implementation

• It concentrates on problem domain to turn it a solution domain.• The sole purpose is to specify how to fulfill the requirements

mentioned in SRS.

Architectural Model• Service Oriented Architecture (SOA)• 3-Tier Architecture• N-Layer Architecture

SOA• SOA is an evolution of distributed computing

based on the request/reply design paradigm. • In this process an application's business logic

or individual functions are modularized and presented as services for consumer/client applications.

3-Tier Architecture• Tier means unit of deployment • A 3-tier application is an application program

that is organized into three major parts, each of which is distributed to a different place or places in a network. The three parts are:• The workstation or presentation interface• The business logic• The database and programming related

to managing it

N-Layer Architecture• It focuses on the grouping of related

functionality within an application into distinct layers.

• In every business software there are FOUR Layer exits, which are Presentation Layer, Business Logic Layer, Data Access Layer and Data Storage Layer.

• These layers (mainly Business and Data Access Layer) should be broken down with several more layers using Class Library Project.

Design Pattern• Repository Pattern:

• In many applications, the business logic accesses data from data stores such as databases or Web services. Directly accessing the data can result in the following:• Duplicated code• A higher potential for programming errors• An inability to easily test the business logic in

isolation from external dependencies• Use a repository to separate the logic that retrieves

the data and maps it to the entity model from the business logic.

• The repository intermediates between the data source layer and the business layers of the application. This will achieve THREE benefits:• It centralizes the data logic or Web service

access logic.• It provides a substitution point for the unit

tests.

Design Pattern• Unit of Work Pattern :

• A Unit of Work can be defined as a collection of operations that succeed or fail as a single unit.

• Unit of Work pattern ensure that none of the operations cause side-effects if any one of them fails.

• It maintains lists of business objects in-memory which have been changed (inserted, updated, or deleted) during a transaction.

• Once the transaction is completed, all these updates are sent as one big unit of work to be persisted physically in a database in one go.

Domain Model• Class Diagram:• To visualize the domain, model a

Class Diagram, have to develop.

• Class diagram is basically a graphical representation of the static view of the system and represents different aspects of the application.

Database Design• Data Dictionary

• Data Dictionary is a collection of descriptions of the data objects or items in a data model.

• Helpful to the programmer to know what data they have to dealt with.

• Data Dictionary may contain following columns:• Data Field• Data Type• Length• Null ability• Default Value• Constraint• Description• Purpose

UX Design• User Experience (UX) and User Interface (UI) are some of the most confused and

misused terms in our field. A UI without UX is like a painter slapping paint onto canvas without thought

• A great product experience starts with UX followed by UI. Both are essential for the product’s success.

UX Design• There should be “Master Page” concept when designing

html pages or forms.

• There should be two “Master Page” in application layer, one for functional pages and another for non-functional pages.

• Functional pages should implement the following master page layout.

• Non-functional pages should implement the following master page layout.

Coding

Coding• Use Pascal Case in Class naming in .NET Technology• Use Pascal Case in Method naming in .NET Technology• Use Camel Case in Variables naming in .NET Technology

• Use Pascal Case in Class naming in Java Technology• Use Camel Case in Method naming in Java Technology• Use Camel Case in Variables naming in Java Technology

Control Naming Guideline

Testing

Testing• Testing Method: Two types are:

• Automated Testing: Automated software testing is a process in which software tools execute pre-scripted tests on a software application before it is released into production.

• Manual Testing: Manual testing is the process of manually testing software for defects. It requires a tester to play the role of an end user and use most of all features of the application to ensure correct behavior.

• White-box Approach:• It focuses on the internal mechanism of a

software system to ensure that all code statements and logical paths are tested.

• testers have to have full knowledge of the internal workings or logics.

• Black-box Approach:• It ignores the internal mechanism and solely

focuses on the outputs generated in response to selected inputs.

• testers do not need to know the internal workings or logic of the software systems

Testing Types• Unit Testing

• is the process of testing the individual subprograms, subroutines, classes, or procedures in a program.

• the goal here is to find discrepancy between the programs and the program specifications

• Programmers to perform Unit Testing after coding is completed. • Testing Approach: White Box testing.

• Integration Testing• The goal is to combine individual software modules and test that module as a group to

identify the faults in the interaction between integrated units.• Test Group to perform Integration Testing; and upon fault found they will issue Test

Incident Reports to system analysts/programmers, who would fix up the liable errors.• Testing approach: Black & White-box testing

Testing Types• Functional Testing

• The goal of functional testing is to verify that a software application performs and functions correctly according to design specifications.

• Functional testing is a way of checking software to ensure that it has all the required functionality that's specified within its functional requirements.

• Test Group to perform Functional Testing; and upon fault found they will issue test incident reports to system analysts/programmers, who would fix up

• Testing Approach: Black-box testing.

Testing Types• System Testing

• Types of testing where a complete and integrated software is tested to identify the errors in software. • The goal is to check the behavior of a complete and fully integrated software based on the software

requirements specification (SRS) document. • The main focus of this testing is to evaluate Business/Functional/End-user requirements.• Test Group to perform system testing; and upon fault found they will issue test incident reports to system

analysts/programmers, who would fix the problem• Testing Approach: Black-box testing.• Some system testing are:

• Usability Testing• UI Testing• Performance Testing• Load Testing• Security Testing

Testing Types• Acceptance Testing

• Acceptance Testing is the process of comparing the application system to its specified requirements and the current needs of its end users. The goal is to determine whether the software end product is acceptable or not by its end users.

• User representatives to perform Acceptance Testing• Testing Approach: Black-box testing.• Acceptance testing are:

• Alpha testing: testing is taken place at the development environment by some end users or user representatives.

• Beta testing: The testing is taken place at the user’s testing environment by users.

Testing Documentation• Test Plan• Test Type: what types (e.g.

functional, system test) of testing is planning to conduct.• Test Item: List the functional items

and software features to be tested. • Estimation: For each test item, list

the estimated effort required and duration

• Test Specification• Testing Environment• Test Termination Criteria• Test Cases

• Test Case Id• Test Title• Priority• Test Steps• Test Data• Expected Result• Actual Result• Pass/Fail

Test Cases• Test cases involve a set of steps, conditions, and inputs that can be used while performing testing tasks.

Test Incident Report• The goal is to document any event that occurs

during the test process which requires investigation.

Test Progress Report• In order to show the progress of the test procedure, a test progress report should be prepared by the

test group.