software requirements

• Requirements Engineering focuses on building usable software for 2024-2025.

The Software Development Cycle

• The steps are: planning, analysis, design, implementation, testing and integration, and maintenance.
• Planning involves defining the: problem, features, and users.
• Analysis involves collecting, analyzing, documenting, and prioritizing requirements.
• Design is about: defining an architecture styles and design patterns.
• Implementation turns requirements into code.
• Testing ensures the software meets requirements and lacks bugs.
• Maintenance includes: updating, modifying, and improving the software after deployment.

Engineering Models

• Software is designed, implemented, and tested incrementally until finished, dividing the system into smaller parts.
• Incremental Model: Uses Deliver Increments, and contains architecture, analysis, design, code, and testing.
• Spiral Model: Fuses iterative prototyping with Waterfall systematic aspects, emphasizing risk analysis at each spiral/iteration.
• Component-Based (CBSE) Model: Breaks project into isolated components, prioritizing the reuse of components across projects.
• Agile Model: Emphasizes iterative development, flexibility, customer satisfaction via stakeholder communication, and iteration improvement.

Model Comparison

• Flexibility: Agile has the most, Waterfall the least, Spiral and Prototyping are in the middle.
• Risk Management: Spiral has the most, others less so, with Waterfall having the least.
• User Involvement: Agile and Prototyping involve it the most; Waterfall the least; Spiral in the middle.
• Development Speed: Agile and Prototyping are fastest; Waterfall the slowest; Spiral being in the middle.

Class Activity: Software System and Model Examples

• E-Commerce Website: Agile.
• Space Exploration Software: Spiral.
• Hospital Management System: Incremental.
• Gaming Engine: Component-based.
• Room booking system: Waterfall.
• Interactive travel planning system use Incremental or Agile methods. Its complex interface benefits from an incremental approach to accommodate changing system requirements.
• Anti-lock braking car system uses Waterfall: Its safety-critical nature needs upfront analysis before implementation.

Learning Objectives for Requirements Engineering

• Goals understanding differences between user and system requirements and functional and non functional ones too.
• Another goal includes describing engineering requirements and analyzing how software ones may be properly specified.

The Requirements Engineering Process overview

• Activities in the process are: feasibility study, requirements elicitation and analysis, requirements specification, and requirements validation.
• Process of establishing what services are required and any constraints.
• It also includes documentation and operation/development.
• The key steps are:
• Elicitation is: Identifying sources.
• Specification is: Classifying requirements, modeling, top-level architecture, negotiating requirements.
• Validation is: Reviews, prototypes, modeling, test definition.
• Documentation is: Creating requirement specifications as standards.

Software Requirements

• Descriptions of system services and constraints, generated during requirements engineering.
• They range from: high-level abstract statements to low-level detailed specifications.
• General Rule: abstract (general) refines to (more detailed and specific).
• "General" statements: Can help with how the system interacts with users/other systems.

Source Examples

• System will maintain library record items like books, newspaper, magazines and videos.
• No item removed without logged borrowing details.
• All items contain a barcode containing a unique identification number.

Sources of Requirements

• Stakeholders can include: decision-makers, end-users, system administrators, engineers, marketing, etc.
• Identifying the problem to be solved is also a source.
• Application Domain: General area that the system is applied.
• Business Context: Interaction and contribution towards business goals.
• Stakeholder needs: Needs constrained in the system.
• Goals/Objectives: Broad outcomes that are achievable, with actionable actions that can meet the goal.

Mentcare System Use Case

• The Mentcare system is an information system is designed for clinics, containing information about patients mental health problems and treatments.
• Purposes: Generating health service management information for performance assessment against local and government targets.
• Purposes: It can also support medical staff with updated timely treatment.
• Features it include: individual care management, patient monitoring, and administrative reporting.

Mentcare Systems Stakeholders

• Patients in the system.
• Doctors assess patients.
• Nurses coordinate with doctors and treatment.
• Receptionist which handle appointments
• Ethical managers: that is current system care guidelines
• Healthcare managers: Who receive data/information from the system
• Medical Records Staff is responsible for maintaining & preserving the system.

Importance of Software Requirements

• Defining precisely what to build is the hardest single part of building a software system and conceptual work.
• Defining requirements impacts everything that is created, including those things interacting with the system.
• If not done correctly it could be more difficult or impossible to rectify.

Requirements Engineering Process

• The team works with all people involves to define discover requirements:
• Finding the domain of the application and its usage.
• Also looking at the the systems services provided and its performance requirements.
• Other information: is what systems currently are being used.
• Stages in the Requirements Engineering Process: Requirements discovery and understanding must be done first.
• Second, Requirements must be classified and organized.
• Next Requirements must be prioritized and negotiated.
• Finally, Requirements documentation must be completed.

Requirements Discovery

• Collection-based Techniques: Interviews, workshops, surveys and questionnaires, job shadowing, focus groups and brainstorming.
• Analysis-Based Techniques: Prototyping, Documenting Analysis, Use Cases and user stories and Benchmarking.

Requirements Elicitation

• Interviews: Using close/(un)structured meetings
• Prototypes: Small system replicas using the diagrams or software.
• Stories and Scenarios: High-level description of system use. Scenarios contain story parts with more detail.
• Observations: Real world work. Review of documentation and manual systems.

KidsTakePics

• Jack a primary school teaches fishing in his class.
• He needs a photo-sharing site because he wants pupils to take pictures on existing photos.
• He needs a site where teachers can check and edit pupil content without intergration.
• With iLearn the pupils can now upload photos from computers immediately.

Scenario: Upload Photos to KidsTakePics

• Digital photos uploaded from either tablet/laptop with logged successful credentials.
• During the upload, users need to be asked to select photos/name with keyword options.
• After upload the automatic email sends the moderator.
• If moderator is not selected there will be an email sent to the administrator for one.

Requirements Classification

• Fucntional: Software functions.
• User interface: Interactions of software.
• System features: System Functions.
• Non-Functional: Performance, scalability, security and availability.

User Requirements and System Requirements

• User Requirements: Abstract statements of system for both the customer
• System Requirements: A detailed description of system's functionality and constraints.
• Requirements example: Generate data from user metrics to generate costing data

Functional Requirements (FR)

• High-level statements to describe the functionalities and/or services the system should provide.
• This Includes reacting to inputs / behaving in certain situations
• It states what the system needs to do rather than what it's intended to do.
• This requirement is known as a High Level Goal

FR Examples

• A user can look up search history logs for all clinics and patients.
• Reports detailing system logs is generated for clinics.
• Logging in must be uniquely identified using 8 digit staff code.

Issues in FR

• Precision: Requirements must be interpreted properly and not too ambiguous.
• Completeness: Descriptions must be included.
• Consistency: There should be no conflcits or contradictions overall.

Non-Functional Requirements (NFR)

• Defines the attributes of system in terms of reliability, response time, performance, security, standards + programming language, etc.
• Limitations on overall services/functionalities offered from the overall system.
• Product Requirements: Requirements that must handle product behaviour, execution etc.
• Organizational Requierments: Policies and processes used.
• External Requirements: Arise from outside factors, like inteoperability requirements.

Dependability Dimensions

• Availability: The system must deliver data even on high loads.
• Reliability: the specific data deliver that's specified
• Safety will be delivered with the catastrophic effect
• The overall system must be secure for delivered data

Metrics for NFR

• Property: Speed, Size or how easy it is of use.
• Measurement: Processed per second, with response time, in rom as size, with time for help.
• Measurement: Time to measure with recovery time, plus more events of potential failure.
• Percentages indicate which level of performance with multiple systems.

Usability

• Easy to use system by medical staff with few errors.
• After the training, the staff should limit the percentage of errors

Canvas Example's

• Functional: Creating courses, uploading course material + secure usernames.
• Non Functional: Scalability, time responsive, Encrypted data & easy user interface to use.

Most Common Reasons Requirements Fail

• Its not needed with objects
• User's opinions aren't needed/known prior
• Don't want to change what's written.

Requirements Prioritization

• MOSCOW Criteria is commonly used and is a great way for specification of requirements
• MOSCOW definitions: Must have, Should have, Could have, Won't have

Requirement Specification

• Take information from the document to analyze requirements to get set of requirements
• The sentences should follow templates where required
• Graphically the models should match usage to sequence diagrams.
• Formal languages: Must use ASMs correctly.

Example: Structured Specification

• Insulin Pump/Control: Safe sugar level
• Computes amount that sugar is needed when level is within level standards.
• Action: If the sugar is stable the compdose is equal to 0, but if it's stable the reading is divided by 4 to be rounded.

UML Use Cases

• Easy to read UML diagrams that describe the Unified language.
• Diagrams are very detailed with other specifications.
• The Users are known as Actors and used cases are represented as ellispes that indicate system interactions.

Requirements Validation

• Any missing requirements are discovered through elicitations
• Users want their system to be the same way that they made it.
• Clarity: Use Precise and clear language
• Requirements: Requirements should be mixed together
• Others: Inconsistent Requirements will occur.

Requirement Checking

• Verify if what you built fits the customer + realistic budget or not
• All features and user stories that occur should be complete
• Consistency - are there any conflicts in requirements
• Need all the requirements to be available in the budget?

Software Specifications Overview

• Defines functionality behaviour, and the overall goals when working through the current system.
• A document that communicates goals with stakeholders by ensuring everything makes sense.

Software Specifications

• Clear + Unambigious
• comprehension with concise documentation for all users.
• Issues includes bad writing of requirements.

Structure of Software Documents

• Intro: Purpose, Scope and Standards
• Overview + Architecture with components and all dependencies / limitations.
• Requirements / Use Cases.
• Glossary of all common terms.

Best Practices

• Use simple language, not jargon
• Be specific + organized .
• Keep it specific + easy to follow the logical flow.

Writing the Introduction

• Explain goals for the audience and overall purpose.
• Use clear concise verbs for tense.

Writing the System Scope

• Purpose to set expectations with others. By clear verb and usage it can set a tone for overall requirements

Funcitonal vs NFR Writing

• In Functinal define the overall what the system needs +
• Non functional adds restrictions over time.

Functional' vs Non

• Funtinal = user should - system
• Non: Music authenticates
• Non: Homepage loads with a query.

Diagram Examples

• UML should illustrate what use case the viewer with class requirements are in relation to all users in specific diagrams

Common Issues

• Lack of clarity
• Too many details
• Lack of audience or knowledge
• No consistency in data.

Closing Statements

• System should set how the system should define the functionality.
• FR and NFR should cover the specific goals
• Documentation must be in order