Software Requirement Analysis and Specifications

• Aims to discuss software requirement analysis and specifications.

Objectives

• To understand the importance of high-quality requirement specifications in software development.
• To identify key system interfaces and their role in system elements.
• To explore information flow, structure definitions, basic diagrams, and major functions.
• To recognize design constraints and technological risks in system development.
• To analyze alternative software requirements and validate the system.
• To address issues like inconsistencies and module redundancy.
• To learn various tools and techniques for determining system requirements.

Software Requirement Specification Topics

• Introduction to Software Requirement Specification
• Software Architecture and Requirement
• Software Requirement Collection
• Software Requirement Classification
• Software Requirement Analysis
• Software Requirement Documentation

Introduction to Software Requirement

• System and software requirements must be documented and reviewed with the customer for further analysis.
• Requirement analysis includes eliciting, analyzing, and recording requirements.
• Eliciting requirements includes communicating with customers and users to determine their requirements, sometimes called requirements gathering.
• Analyzing requirements involves determining whether the stated requirements are unclear, incomplete, ambiguous, or contradictory, and then resolving these issues.
• Recording requirements may be in various forms, such as natural-language documents, use cases, user stories, or process specifications.

Success Factors for Software Development

• The level of detail in which the team activities are recorded.
• The quality of the software specification.
• The integrity of the software specification.
• The accuracy of the software specification.
• Established development processes.
• Rigor with which the established processes are followed.
• The quality and number of reviews and audits.
• The accuracy of the models used to estimate software attributes.
• The effectiveness of the test and integration plan, specification, and test data.
• The level of preparation for system maintenance.

Software Requirement Specification (SRS)

• SRS provides a complete description of the behavior of the system to be developed that includes a set of use cases.
• Use cases are also known as functional requirements.
• Non-functional requirements impose constraints on the design or implementation.

Two analysis phases exist

• Planning results in system definition, a project plan, and a preliminary user manual.
• Software requirement definition activity is recorded in the software specification.
• Technical requirements for the software product will be specified completely, concisely, and unambiguously.

Example Table of Contents for SRS

• Introduction
• General description
• Functional Requirements
• Interface Requirements
• Performance Requirements
• Design Constraints
• Non-Functional Attributes
• Preliminary Schedule and Budget
• Appendices
• Uses of SRS document
• FAQs on SRS Format
• Conclusion

Types of Software Requirements

• Functional - Describe what the software should do and define the functions or features the system must have.
• Non-Functional - Describe how the software performs a task rather than what it should do that define the quality attributes, performance criteria, and constraints.
• Domain - Specific to the domain or industry in which the software operates, and include terminology, rules, and standards relevant to that particular domain.

Examples of functional requirements

• User Authentication: The system must allow users to log in using a username and password.
• Search Functionality: The software should enable users to search for products by name or category.
• Report Generation: The system should be able to generate sales reports for a specified date range.

Examples of Non Functional Software Requirements

• Performance: The system should process 1,000 transactions per second.
• Usability: The software should be easy to use and have a user-friendly interface.
• Reliability: The system must have 99.9% uptime.
• Security: Data must be encrypted during transmission and storage.

Examples of Domain Software Requirements

• Healthcare: The software must comply with HIPAA regulations for handling patient data.
• Finance: The system should adhere to GAAP standards for financial reporting.
• E-commerce: The software should support various payment gateways like PayPal, Stripe, and credit cards.

Additional Definitions for Software Requirements

• Performance requirements should be developed interactively across all functions, and characterized by certainty, criticality to system success, and relationships with other requirements.
• “Design” includes“build to,” “code to,” and “buy to" requirements for products and “how to execute requirements for processes expressed in technical data packages and technical manuals.
• “Allocated” refers to a requirement established by dividing or allocating a high-level requirement into multiple lower-level ones.
• “Derived” refers to requirements that are implied or transformed from the higher-level requirements.

Software Architecture

• Software architecture defines the fundamental structure and organization of a system.
• Specifies how components are assembled and how they communicate.
• Serves as a blueprint for software development.
• Simplifies the development process by offering a framework that ensures consistency and efficiency.
• Defines the structure of a system, behavior of a system, component relationships, and communication structure.
• Balances stakeholder's needs, influence team structure, focuses on significant elements, and captures early design decisions.

Importance of Software Architecture:

• It’s a key part of the design phase in the software development life cycle and one of the initial steps in the process.
• Proceeding without it is like building a house without a blueprint.
• Plays a critical role in software application development by selecting quality attributes that can be optimized, facilitates early prototyping, allows systems to be built in component wise, and helps in managing changes in the system/s.

Software Requirement Collection principles for a System Analyst

• Impertinence: Question everything.
• Impartiality: Find the best solution for a business problem.
• Relaxed constraints: Assume anything is possible and eliminate the infeasible.
• Attention to detail: Every fact must fit with every other fact.
• Reframing: Analysis is a creative process.

Requirement Determination Deliverables include:

• Information collected from conversations with users i.e. interview transcripts, questionnaire responses, meeting minutes, etc.
• Existing written information i.e. Business strategy statements, sample business and reports, procedures, manuals, documentation etc.
• Computer-based information i.e. Joint application design sessions, CASE repository contents, system prototypes.

Traditional Methods for System Requirements

• Interviews and Questionnaires
• Listening
• Observations

Questionnaire facts

• Choose a representative sample
• Design a questionnaire that covers all requirements
• Conduct group discussion and brainstorming
• Document and analyze all the findings

Modern Methods for System Requirement collection

• Joint application development (JAD) involves users, managers, and analysts working together to design to develop software applications.
• Objective is to bring key users, managers, and system analysts together to discuss needs.
• This group defines new system requirements, designs a solution and monitors project until completed.

Typical JAD Participants

• JAD Leader: Organizes the session, sets the agenda, and keeps the discussion on track.
• Key Users: People who use the system directly and understand the daily operations
• Managers: Provide insight into organizational goals
• Sponsor: Overall director and support
• System Analysts: Learn from users and managers to gather requirements
• Scribes: Document the session discussions
• IT staff: provide support for feasibility and implementation

JAD Advantages

• Improved Collaboration and efficiency
• Increased effectiveness for development
• Enhanced quality and user satisfaction

CASE tools in JAD

• Running a CASE tool during JAD allows analysts to enter system models directly in a CASE tool, providing a strong reliability and consistency on joint model building process.

GSS with JAD

• Group Support Systems (GSS) can be used to support group meetings and alleviate problems that can be caused in group meetings.

Prototyping for system requirement is useful

• When users cannot specify the requirements in advance.
• When the desired system cannot be visualized
• When the environment is new and not well understood by participants

Model defines for activities in software requirement collection

• Define Goals: Specific Goals are identified such as cost reduction, faster processing, or employee empowerment
• Identify Processes: Determine which processes need improvement.
• Evaluate Processes: Understanding their strength and weaknesses by analyzing
• Design New Processes: Creating new and better practices
• Test New Processes: Improving prototypes before implementation
• Implement New Processes: Integrate improved process into the business.

Seven Principles of Re-engineering by Michael Hammer and James Champy to Streamline Work Process

• Organize around outcomes and costs
• Identify and prioritize processes for redesign depending on urgency for said redesign
• Integrate information processing work into real work
• Treating geographically dispersed resources as they are centralized.
• Linking parallel activities instead of integrating results
• Putting decision point where work is performed
• Capturing information and at the source.

Types of Customer Requirements

• Operational distribution or deployment: Where will the system be used?
• Mission profile or scenario: How will the system accomplish its mission objective?
• Performance and related parameters: What are the critical system parameters to accomplish the mission?
• Utilization environments: How are the various system components to be used?
• Effectiveness requirements: How effective or efficient must the system be in performing its mission?
• Operational life cycle: How long will the system be in use by the user?
• Environment: What environments will the system be expected to operate effectively?

Software Requirement Analysis

• It is known as requirements engineering concerned with the goals, functions, and constraints of software systems.
• It is a sub-discipline of systems engineering beginning with a feasibility study, leading to a feasibility report.
• Requirements analysis determines the needs and conditions for new or modified products while addressing conflicting requirements from stakeholders, such as users and beneficiaries.

Software Requirement Documentation

• It provides a detailed description of what the software is or is expected to do.
• Documentation acts as a central reference point throughout development.
• Documentation acts as a communication tool and a basis for agreements.
• The documentation is essential for guiding the development process.

Technical Documentation

• It refers to software documentation detailing various aspects of operation, written by API writers
• Code documentation should be detailed yet concise for easy maintenance
• Documentation includes guides that include developers, testers, and end-users to interact with the software.

User Documentation

• It focuses on describing how the software is used rather than detailing its source code.
• Explains features and guides users on how to utilize them effectively.
• It includes troubleshooting assistance to help resolve issues.
• Documentation should be clear, up-to-date, and easy to understand.
• Emphasizes consistency and simplicity to ensure usability.

Organizing user documentation through three broad ways

• Tutorial: Guides new users step-by-step through tasks
• Thematic: Focuses on specific areas or topics in chapters or sections
• List of Reference: Grouping commands or tasks logically with cross-referenced index.