1. Software Requirement Specification concept.

An SRS gives you a complete picture of your entire project. It provides a single source
of truth that every team involved in development will follow. It is your plan of action
and keeps all your teams — from development to maintenance.

Software Requirements Specification vs. System Requirements Specification :

• A software requirements specification (SRS) includes in-depth descriptions of the

software that will be developed.
• A system requirements specification (SyRS) collects information on the
requirements for a system.

A software requirements specification (SRS) is a document that describes what the

software will do and how it will be expected to perform. It also describes the
functionality the product needs to fulfill all stakeholders (business, users) needs.

An SRS can be simply summarized into four Ds:

1. Define your product's purpose.

2. Describe what you're building.
3. Detail the requirements.
4. Deliver it for approval.

A software requirement can be of 3 types:

1. Functional requirements
2. Non-functional requirements
3. Domain requirements

2. Write down CMMI requirement management process

● The purpose of Requirements Management (REQM) (CMMI-DEV) is to manage

requirements of the project’s products and product components and to ensure
alignment between those requirements and the project’s plans and work
products.

● The Capability Maturity Model Integration (CMMI) is a process and behavioral

model that helps organizations streamline process improvement and encourage
productive, efficient behaviors that decrease risks in software, product, and
 service development.
● The purpose of Requirements Management (REQM) (CMMI-DEV) is to manage
requirements of the project’s products and product components and to ensure
alignment between those requirements and the project’s plans and work
products.

● The Capability Maturity Model Integration (CMMI) is a process and behavioral

model that helps organizations streamline process improvement and encourage
productive, efficient behaviors that decrease risks in software, product, and
service development.

The CMM Integration is a model that has integrated several disciplines/bodies of

knowledge. Currently there are four bodies of knowledge available to helping for
selecting a CMMI model.

● Systems Engineering
● Software Engineering
● Integrated Product and Process Development
● Supplier Sourcing

The CMMI is structured as follows −

• Maturity Levels (staged representation) or Capability Levels
(continuous representation)
• Process Areas
• Goals: Generic and Specific
• Common Features
• Practices: Generic and Specific

CMMI models with staged representation, have five maturity levels designated by the
numbers 1 through 5. They are −

• Initial
• Managed
• Defined
• Quantitatively Managed
• Optimizing
 3. Methodology of Software Requirement Elicitation (through benchmark
products, research papers, similar organization, online materials etc. )

Elicitation methodologies:
a. Acquired documents from client
b. Compared Benchmark Applications
c. Read Research Papers
d. Survey
e. Brainstorming
f. Interface Analysis
g. Document analysis
h. One and one interview including budgets and timelines
i. Group Interview with company department personnel

Information sources (doma understadig)

 A. Client, Head of Department (Initiator)
B. Client and their Employees (End User)
C. Onsite Visits
D. Leaders (Primary User)
E. Employees (Secondary User)
F. Market Research Observation
G. Internet Research
H. Collecting data from different vendors (If needed)
I. Prototyping
J. Creative thinking

4. Determine your software project’s specification through the software

elicitation and gap analysis approach

● Existing System
○ Analysing the existing system(Manual Operation)
● User Interface Analysis
○ No existing Interface instead BRD by client was prioritized
○ There were 34 total requirements including functional &
non-functional requirements
● BenchMark Products
○ HOA Life
○ HOA Express
● Research Papers
○ Link By Robert A. Ochoa 2009

● The problems with current system and solution:

○ Many employees input data without identification, no way to trace
back faulty data (User profiles)
○ Too many google forms, spreadsheets and databases to keep track
of, update and use (one system)
○ No way to view data in clean and presentable format (Interface)
○ No way to see employee progress and track performance
(Performance analytics)
○ Manual invoicing and calculation takes very long time (automated
invoicing)

● Ideal future state

 ○ Different User profiles for different rank of employees
○ Data input form
○ Data output documents
○ Data viewing interface
○ Employee work analytics
○ Invoice generator
○ All operations under one system
○ Clean database
○ Readable data representation

● Classification
● Conflict resolution
● Prioritization
● Requirement checking

5. Concept of different types of requirements/specifications (functional,

non-functional, domain )
❖ Functional Requirements (mentioned expectations):
➢ Software requirements specification (from clients side requirements
too)
➢ Technical details, Data/Reports processing expectations etc.
❖ Non-Functional Requirements (non-mentioned expectations):
➢ Operational Requirements (portability, maintainability)
➢ Performance Requirements (speed, capacity)
➢ Security Requirements (digital certificate, access control, reliability)
➢ Cultural and Political Requirements (social, language, legal,
unstated norms etc.)
❖ Domain requirements are the requirements which are characteristic of a
particular category or domain of projects.

Functional Requirements should include:

● Descriptions of data to be entered into the system
● Descriptions of operations performed by each screen
● Descriptions of work-flows performed by the system
● Descriptions of system reports or other outputs
● Who can enter the data into the system
● How the system meets applicable regulatory requirements

Non functional requirements basically deal with issues like:

● Portability
● Security
 ● Maintainability
● Reliability
● Scalability
● Performance
● Reusability
● Flexibility

NFR’s are classified into following types:

● Interface constraints
● Performance constraints: response time, security,storage space, etc.
● Operating constraints
● Life cycle constraints: maintainability, portability, etc.
● Economic constraints

Why use domain requirements?

● To make the system workable
● If not satisfied, the system may not work

6. Illustrate software requirements/specifications validation-verification

techniques
7. Draw and Illustrate on requirement engineering model

8. Concept of software requirement designing. Draw Use Case Diagram.

Activity diagram/ Flow chart for some major use cases.

9. Write down some common principles on UI design

● Create clutter-free, simple designs, engaging, common format UI designs -
Jacob’s Law, Aesthetic Usability Effect, Pragnanz, Tesler’s Law
● Make sure the action button is always easy to find - Fitt’s Law, Von Restorff Effect
● Create responsive designs with progress bars - Goal Gradient Effect
● Minimize choices - Hick’s Law, Miller’s Law, Occam’s Law
● Be thoughtful in the way you group elements together - Common Region, Law of
Proximity, Uniform Connectedness, Law of Similarity
● Focus on areas that users interact with the most - Peak End Rule
● Position key elements on the far right or left in your design - Serial Position Effect
● Make sure actions take short time - Doherty Threshold, Parkinson’s Law
● Reduce number of clicks to goal - Pareto Principle
● Be flexible of user action possibility - Postel’s Law