MSS Flashcards
(33 cards)
Functional and Non-functional Requirements:
Functional Requirements:
Define specific operations or features the system must perform.
Examples: User authentication, inventory management, processing payments.
These requirements describe what the system should do and focus on the functionality that the end-user expects from the system.
Characteristics: Clear, measurable, and testable. Each functional requirement typically includes input, process, and output.
Non-functional Requirements:
Define the system’s operational qualities or constraints.
Examples: Performance, security, usability, reliability, scalability.
They describe how the system performs its tasks, including conditions under which the software must operate (e.g., handling 1,000 transactions per second).
Characteristics: Often involve quality attributes like speed, capacity, security, and compliance.
Requirements Engineering Processes:
Requirements engineering refers to the systematic process of gathering, analyzing, documenting, validating, and managing the software system’s requirements.
It includes the following stages:
Requirements Elicitation: Collecting requirements from stakeholders.
Requirements Analysis: Refining and resolving conflicts in requirements.
Requirements Specification: Documenting requirements in a clear and detailed manner.
Requirements Validation: Ensuring that the requirements are correct, feasible, and meet stakeholder needs.
Requirements Elicitation:
The process of gathering requirements from stakeholders, including users, customers, and system engineers.
Techniques:
Interviews: Direct discussions with stakeholders to gather requirements.
Surveys/Questionnaires: Collecting input from a large group of stakeholders.
Workshops: Group discussions that involve multiple stakeholders to gather consensus on requirements.
Prototyping: Creating early versions of the system to clarify requirements.
Observation: Watching users interact with current systems to understand their needs.
Challenges:
Handling conflicting requirements between different stakeholders.
Ensuring all requirements are complete and clearly communicated.
Requirements Validation:
his process checks that the gathered requirements meet stakeholder needs and are feasible to implement.
Methods:
Review Meetings: Stakeholders review and approve requirements.
Prototyping: Validates requirements by providing a working model.
Walkthroughs: Developers and stakeholders discuss each requirement to ensure clarity and agreement.
Formal Inspections: A thorough, formal review of the requirements documentation.
Goal: Identify and correct errors, omissions, or misunderstandings in the requirements before the design or implementation begins.
Requirements Change
Changes in requirements are common due to evolving business needs, new market demands, or unforeseen technical challenges.
Reasons for Change:
New user needs or features.
Changes in regulations or industry standards.
Budget or time constraints.
Managing Change:
A formal Change Control Process is needed, involving the submission of change requests.
Impact Analysis: Evaluating the effect of the proposed change on the system’s scope, schedule, and cost.
Prioritizing changes based on their importance and the project’s timeline.
Documentation and re-validation of updated requirements.
Traceability Matrix:
A document that maps each requirement to its corresponding design elements, code, and test cases to ensure full coverage.
Purpose:
Helps in tracking the implementation of each requirement.
Ensures that every requirement has been accounted for in the final system.
Helps in change management by showing the impact of changes to any requirement.
Types of Traceability:
Forward Traceability: Maps requirements to design and code to ensure the system reflects all requirements.
Backward Traceability: Ensures that design and code can be traced back to the original requirements.
Developing Use Cases:
Use Case: A written description of how users will interact with the system to achieve a specific goal.
Components:
Actors: The users or systems that interact with the software.
Scenario: Describes the steps taken by the actor to achieve a goal.
Extensions: Describe alternative flows or error handling.
Purpose: Helps in defining functional requirements by showing how the system should behave in real-world scenarios.
Software Requirements Specification (SRS):
Definition: A comprehensive document that outlines the system’s functional and non-functional requirements.
Template:
Introduction: Purpose, scope, and definitions of the system.
Overall Description: General factors that affect the product and its requirements (e.g., product perspective, user characteristics).
Specific Requirements: Detailed functional requirements, interfaces, and performance criteria.
Importance: Acts as a formal contract between stakeholders and developers and provides a reference throughout development.
Personas:
Definition: Fictional characters created to represent different user types that might use a system in a similar way.
Purpose: Helps developers and designers understand the goals, behaviors, and pain points of typical users.
Components:
Name and background.
Demographics: Age, job, interests.
Goals and challenges: What the user wants to accomplish using the system.
Scenarios:
Definition: Detailed narratives that describe how a user (often represented by a persona) would interact with the system in a specific situation.
Purpose: Provides context for how users will use the system, helping in the development of use cases.
Example: A scenario describing how a persona would use a mobile app to book a flight ticket.
User Stories:
Definition: Simple, informal descriptions of a feature written from the user’s perspective.
Format: “As a [type of user], I want to [perform an action], so that [achieve a goal].”
Purpose: Used in Agile development to define features in a user-centric way. Helps developers understand the value of the feature and the user’s needs.
Example: “As a customer, I want to receive email notifications when my order ships so that I can track the delivery.”
Feature Identification:
The process of identifying and defining key features of the software that are necessary to fulfill the requirements.
Approach:
Derive features from functional requirements, use cases, and user stories.
Features can be categorized as essential, desirable, or optional.
Example: For an e-commerce platform, features include user registration, product search, shopping cart, and payment processing.
Design Concepts:
Definition: High-level ideas and principles that guide the design of a software system.
Key Concepts:
Modularity: Breaking down the system into independent modules or components.
Abstraction: Hiding the complexity of the system by focusing on high-level functionality.
Encapsulation: Restricting direct access to some of an object’s components, which is a form of information hiding
.
Cohesion and Coupling:
Cohesion: Measures how closely related the functionalities of a single module are.
Coupling: Refers to the interdependencies between modules. Low coupling is preferred for better maintainability.
Importance: Helps ensure that the system is scalable, maintainable, and adaptable to change.
What is Software Engineering?
The application of engineering principles to software development in a systematic, disciplined, and quantifiable approach. It covers everything from requirement gathering to software design, coding, testing, and maintenance
Importance: Software is central to society, businesses, and governments. Proper software engineering reduces software failures and the costs associated with maintaining and updating systems
Professional Software Development
Definition: Involves building software systems intended for use by others. This type of development usually involves teams of software engineers and focuses on creating reliable, maintainable, and scalable products
Types:
Generic Software: Packaged and sold to multiple customers (e.g., mobile apps, office tools).
Customized Software: Built specifically for an individual customer or organization (e.g., airline reservation systems, banking systems)
Software Engineering Ethics
Key Principles:
Confidentiality: Keep client information private, even without a formal agreement.
Competence: Do not accept work outside your skill level.
Intellectual Property: Respect laws regarding patents, copyrights, and software ownership.
Computer Misuse: Avoid unethical practices like hacking or unauthorized access to data
Software Process Models
Software process models describe how software is developed in a structured, organized manner. Each model has a unique approach to managing the stages of software creation.
The 4 Fundamental Activities
Regardless of the model used, all software processes include the following steps:
Software Specification: What should the software do? (Requirements gathering and analysis).
Software Development: Building the software according to specifications.
Software Validation: Testing to ensure the software works as intended.
Software Evolution: Updating and modifying the software as user needs change
The Waterfall Model
The Waterfall Model
What is it?: A sequential, phase-based model where each phase must be completed before moving to the next. It’s structured in a linear fashion.
Phases:
Requirements Analysis: Determine the software’s functions and constraints.
System and Software Design: Create the architecture and structure.
Implementation and Unit Testing: Build the software and test individual components.
Integration and System Testing: Test the complete system to ensure it meets requirements.
Operation and Maintenance: The software is delivered, and any issues are addressed
.
Where it Works Best: Projects with clear, well-understood requirements and minimal change during development
It’s simple but rigid, making it ideal for projects with clearly defined requirements
Incremental Development
Incremental development allows the software to evolve through multiple versions (increments). Each version builds on the previous one, adding functionality based on user feedback. It’s flexible and widely used for software that needs to adapt during development
Instead of building the system all at once, incremental development delivers the system in small, usable parts
Key Points:
Users provide feedback after each increment, which is used to adjust and improve subsequent releases.
Early delivery of basic functionality, with more features added incrementally.
Reduces the impact of changing requirements
Advantages:
Flexibility: Easier to adapt to new requirements.
User Feedback: Enables continuous improvement through user input.
Drawbacks: Documenting and maintaining the system structure can become difficult over time
Software Specification
What is it?: The process of understanding and documenting what the system should do.
Steps:
Requirements Elicitation and Analysis: Gathering needs from stakeholders.
Requirements Specification: Writing down the requirements in a detailed document.
Requirements Validation: Ensuring the requirements are realistic, complete, and consistent
Integration and Configuration Model
What is it?: This model focuses on reusing existing software components and integrating them into a new system.
Steps:
Requirements Specification: Define system needs based on available components.
Software Discovery and Evaluation: Search for reusable components that match requirements.
Configuration and Adaptation: Modify components to fit system requirements.
Integration: Bring all components together into a functional system
Advantages: Speeds up development by using pre-existing components.
Drawbacks: Limited customization because you’re working within the constraints of the existing components
Process Activities
Software Specification: Gathering requirements and defining what the software will do.
Software Design: Structuring the software and defining how it will work.
Software Implementation: Writing the actual code to build the software.
Software Validation: Testing the software to ensure it meets requirements.
Software Evolution: Updating the software as new requirements arise
Software Design and Implementation
Design: This involves defining the overall architecture of the system, including data models, component relationships, and algorithms.
Implementation: Translating the design into actual code, often using development tools to simplify this process
Software Validation
What is it?: The process of testing the software to make sure it works as expected.
Types of Testing:
Component Testing: Testing individual parts (e.g., functions or modules).
System Testing: Testing the entire system to ensure all parts work together.
Customer Testing: Testing with real-world data provided by the client
