Software Requirement Analysis

• Requirement analysis is a crucial SDLC phase involving stakeholder need understanding, detailed information gathering, and clear requirement documentation.
• The goal is to establish a comprehensive understanding of what a software system should do and how it should function.

Types of Requirements

• Functional requirements describe what a system should do, specifying its functionalities, features, and actions, such as login, data storage, and report generation.
• Non-functional requirements focus on the quality attributes of a system, how well it performs, its design, and constraints, including performance, security, usability, and reliability requirements.

Key Steps

• Elicitation
• Analysis
• Documentation
• Validation
• Management

Elicitation Techniques

• Interviews
• Surveys and Questionnaires
• Workshops
• Prototyping
• Observation

Importance of Validation

• Validation addresses the needs and expectations of stakeholders.
• It verifies accuracy, completeness, consistency, and feasibility of requirements.
• Errors, inconsistencies, or missing information are identified and addressed.
• Validation builds trust and confidence among stakeholders, aligning them on goals and objectives.

Common Challenges

• Requirements analysis faces challenges such as ambiguous/conflicting needs.
• Also changing requirements and lack of communication.
• Technical limitations and user elicitation difficulties also pose issues.

Qualities of Good Requirements

• Good requirements should be clear, concise and easy to understand.
• Good requirements should also be complete, containing all necessary information for implementation and testing.
• Free from contradictions and conflicting information.
• Testable to guarantee it meets required criteria.
• Defined to be realistic and achievable within technical and resource constraints.

Mistakes to Avoid

• Avoid assuming understanding, ignoring user needs, and failing to document, review, and validate requirements.
• Avoid Procrastinating requirements

Business Analyst Role

• Business analysts elicit, analyze, document, validate, and communicate needs and manage changes.

Best Practices for Real-Time Data Processing Systems:

• Best practices include understanding real-time constraints.
• Practices also describe defining data flow/processing and considering concurrency/synchronization.
• Thorough testing for real-time performance is also performed.

Plan Driven vs Agile

• Fred Brook states the most important function that the software builder performs for the client is the iterative extraction and refinement of the product requirements

Plan-Driven Development

• Plan driven development uses a software development method attempting to plan and develop all features a user might want and details how such features are developed.
• It includes organizing the team and member roles.
• Risk Analysis and Probabilities as well as Hardware and software resource requirements should also be considered.
• Decide Activities, Deliveries, and Milestones and allot of needed people/time.
• Establish Monitoring or Reporting systems.

Plan-Driven - PDD Advantages

• PDD requires knowledgeable personnel at the beginning and fits big software development/extensive systems.
• PDD grips hazardous systems efficiently and fits stable growth environment.
• PDD also provides achievement attained through construction and directive.

Plan-Driven - PDD Disadvantages

• PDD does not allow changes at anytime.
• Repetition distances are longer and future variation can not occur.
• User-particpation is limited and expenses for dynamic expansion environment can increase.

Agile Development

• Agile helps adapt to project with change requests with aim to facilitate quick project completion for greater agility.
• Agility is achieved by fitting the process to the project with limited activities for a specific project.
• Agile's highest priority is to satisfy the customer through early and continuous delivery of valuable software

Agile Advantages

• Changing requirements are welcome, even late in development, and processes harness a more competitive advantage.
• It provides faster deliver working software between weeks or months and should support shorter timescales.
• Allows people/developers to constantly work together throughout a project
• Agile best architectures, requirements, and designs emerge from self-organizing teams.
• Allows agile teams to regularly reflect and tunes/adjust behavior for better effectiveness.
• Allows the most efficient and effective means to conveying information from face-to-face conversations.

Agile Disadvantages

• Agile's flexibility at the core allows much lower predictability, making estimates difficult for resources/efforts for project completion.
• This can lead to uncertainty, frustrations, and poor decisions.
• It requires more time and commitments but can negatively impact quality if one is not on-board.
• Development requires constant collaboration, taking more time/energy for everyone.
• Tasks are often completed quickly, which also reduces extensive documentation leads misunderstandings.
• Agile projects are less structured and easily run astray or stray from original scope.

Agile vs V-Model

• The Agile Model differs compared to V-model in that the project continues to test a developing the software simultaneously.
• The V-Model is reliable than the Agile Model, as it tests once completed entirely.

Differences Summarized

• Agile models create concurrent while the V model does not.
• Agile creates multiple sprints as verification/validation processes.
• Agile models is compared to v-models for easy testing and communications between teams.
• Agile models consist of a total of 5 phases while the V model does not.
• Agile's developers/testers are connected compared to the others independence.
• Agile is iterative an incremental testing compared to the V models process.
• In general agile handles smaller and large projects compared to V which handles the reverse.
• Coding/testing is more focused in Agile while design is the sole focus in the V models.
• Agile models test working software sooner in a proactive method.
• V operates on a reactive process, rigid, and a longer testing time than Agile.

Requirements

• Functional requirements list features the user will see/use when program starts
• A plan driven process requires functional specification documents for of identifying requirements for a functional system.
• A agile process uses User Stories to define product backlog.
• During your project, requirements are uncovered as a diverse set of User, Domain, Nonfunctional, and Non requirements.

What types are we talking about?

• It is important to learn and build the best type of programs from super-programmer mindsets.

User Requirements

• Provide details and support in natural language of screen layouts, dialog boxes, and menus.
• Describes any program in the user requirements.

Domain Requirements

• Detailed requirements give developers important insight for design.
• Layer software as applications below the user and network interfaces.
• API's are implemented with separate classes and libraries.
• Domain users should only affect the application with concern to the user.

Non-Requirements

• Non functional requirements creates services and functions for expectations.
• These expectations provide security requirements, files, and other memory data.
• These include requirements that provide the overall experience on what the app provides when loading.

The Gathering in Plan-Driven Project

• Functional documents creates perspective from specified screens, manuals, and dialogs.
• The technical reports details program, database, models, data structures, and language.

Outlining Functional Specification

• Diverse elements are applied as the program differs and the project grows.
• Scenarios in a list are displayed.
• Issues are resolved by receiving customer help.
• Features and Design notes create better marketing with better implementation ideas.

Agile Requirement Analysis

• Agile follows an iterative process of improving software with frequent feedback.

Requirements Gathering

• Agile development project often does not have a full functional specification document.
• From previous requirements, Agile developers should embrace change and defer the making of future design as long as possible. By doing so, designers will have less of a scope.
• The immediate feedback allows them to take data and give updates to the customers.

Card System

• Users write user stories that allow a card system to provide post it notes, index cards and physical devices.
• User Stories should also implement a ROLE as it performs an specific ACTION due to REASONS .

Stories -INVEST in

• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

Stakeholders in Agile

• Conversation and the product stakeholders take their part in design to better represent project.
• This includes users, product testers, development, and market team.
• By building confirmation processes and criteria lists, teams will use their implementation skills and processes better.