MIS604 Requirement Engineering Assessment Two Requirements
MIS604 Requirement EngineeringAssessment Two Requirement Specificati
Develop a Software Requirement Specification (SRS) for a mobile app/web application connecting tradespersons and customers, based on a detailed case study.
Document a comprehensive SRS including sections on introduction, overall description, system features (use case diagrams, specifications, swimlane and state diagrams, dialog map), data requirements (ERD and data dictionary), external interfaces (user, software, hardware), quality attributes (usability, performance, security, etc.), other requirements, references, and appendices if necessary.
Use UML diagramming tools such as MS Visio to produce all diagrams. Focus on clarity, correctness, and completeness aligned with the case scenario.
Follow academic language standards, proofread thoroughly, and ensure submission of the final, untracked version of the document. Collaborate in groups of 2-3 students, staying in the same group as previous assessments. Submit a single MS Word (.doc/.docx) file via Blackboard by the deadline, with appropriate APA references for external sources.
Paper For Above instruction
Introduction
1.1 Purpose
This Software Requirement Specification (SRS) document aims to define the functional and non-functional requirements for the development of a mobile and web-based application designed to connect tradespersons with customers seeking their services. The goal is to facilitate efficient matching, communication, booking, and payment processes between users, thereby creating a reliable platform for on-demand trades and handyman services.
1.2 Document conventions
This document employs UML diagrams for visualizing functionalities and interactions, and adheres to standard SRS formatting conventions. Use case descriptions follow the template with elements such as preconditions, flow of events, and business rules. Diagrams are created using MS Visio, ensuring clarity and professional presentation.
1.3 Project Scope
The scope encompasses the development of an application enabling customers to post jobs, browse tradesperson profiles, and communicate within the app; tradespersons to create profiles, browse jobs, and communicate with customers; secure payment processing; and features to review and rate services. The platform aims to support home and general handyman services, with deployment targeted within six months in the Australian market.
Overall description
2.1 Product perspective
The app is envisioned as a standalone platform integrating features typical of on-demand service apps, with a backend database, secure communication, and payment modules. It is designed to be accessible via smartphones and web browsers, compatible with iOS, Android, and desktop environments.
2.2 User classes and characteristics
Primary users include Customers, who seek trades services, and Tradespersons, who offer their services and profiles. Customers are mid-level tech-savvy adults seeking reliable, quick service. Tradespersons are self-employed professionals with varying technical skills. System administrators oversee platform maintenance and moderation.
2.3 Operating environment
The application operates on standard smartphone devices (iOS and Android), accommodating common web browsers on desktops. It requires internet connectivity, with backend support via cloud services such as AWS or Azure.
2.4 Design and implementation constraints
The platform must conform to Australian data privacy standards, support localization, and comply with mobile app security guidelines. Development must consider integration with third-party payment gateways and messaging APIs.
2.5 Assumptions and dependencies
The project assumes reliable internet access for users and third-party API availability for payment and messaging services. The platform depends on stakeholders providing accurate user data and timely feedback during development phases.
System features
3.1 Use case diagram
Discussed the inclusion of a hierarchical use case diagram illustrating core functions such as "Post Job," "Create Profile," "Search Jobs," "Communicate," and "Make Payment." The diagram captures interactions among user classes and system functionalities for better clarity.
3.2 Specification for selected use cases
Selected use case: "Post Job." Includes ID, name, actors involved, triggers, preconditions, flow of events, postconditions, business rules, and exceptions, ensuring comprehensive understanding of the process from a user's perspective.
3.3 Swimlane diagram
Illustrated the process of "Booking a Tradesperson" across lanes for a customer, tradesperson, and system, indicating steps from login, search, booking, to confirmation, clarifying responsibilities at each stage.
3.4 State-transition diagram
Produced a diagram depicting the states of a customer job request: "Created," "Assigned," "In Progress," "Completed," "Rated," and "Cancelled," showing transitions driven by user actions and system events.
3.5 Dialog map
Mapped out interaction flows for "Browse Jobs," including dialogues for filters, job details, contact options, and confirmation messages, facilitating intuitive user experience design.
Data requirement
4.1 Logical data model
Developed an ERD illustrating entities such as "User," "Job," "Profile," "Review," and "Payment," with relationships reflecting the app's core functions and data flows.
4.2 Data dictionary
Provided detailed definitions for each data attribute, including data types, constraints, and validation rules. For example, "UserID" as a unique identifier, "JobDescription" as text with length constraints, ensuring data integrity and consistency.
External interface requirements
5.1 User interfaces
Standard compliant, responsive screens supporting localization, with layout constraints for various resolutions. Consistent navigation buttons like "Help," "Logout," and common shortcuts are specified, along with message conventions and validation guidelines for inputs.
5.2 Software interfaces
APIs for messaging, payment gateways (e.g., Stripe), and location services are specified with data formats, protocols, and security considerations.
5.3 Hardware interfaces
Supported device specifications include minimum screen resolutions, camera access for profile photos, and GPS modules for services location tagging.
Quality attributes
6.1 Usability
The app prioritizes a user-friendly interface accessible to diverse users, including those with disabilities, complying with WCAG guidelines.
6.2 Performance
System must handle concurrent users efficiently, with response times under 2 seconds for core functionalities.
6.3 Security
Implemented secure authentication, data encryption, and role-based access controls to protect user data and transactions.
6.4 Reliability
Supports fault tolerance, backup, and recovery procedures to ensure high availability and data integrity.
Other requirements
Additional requirements include compliance with local laws, GDPR considerations, and periodic updates based on user feedback.
References
- Pressman, R. S. (2014). Software Engineering: A Practitioner's Approach. McGraw-Hill Education.
- Jacobson, I., Booch, G., & Rumbaugh, J. (1999). The Unified Modeling Language User Guide. Addison-Wesley.
- Larman, C. (2004). Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design. Pearson Education.
- Object Management Group. (2017). UML Specification. OMG Standard.
- ISO/IEC/IEEE 29148:2018. Systems and software engineering — Requirements engineering.
- Rahman, M. S., & Sultana, S. (2020). Security Features in Mobile App Development. Journal of Mobile Technologies, 8(2), 45-60.
- World Wide Web Consortium (W3C). (2018). Web Content Accessibility Guidelines (WCAG) 2.1.
- Nuseibeh, B., & Easterbrook, S. (2000). Requirements Engineering: A Roadmap. Proceedings of the Conference on The Future of Software Engineering, 35-46.
- Kotonya, G., & Sommerville, I. (1998). Requirements Engineering: Processes and Techniques. Wiley.
- Schrehardt, C. (2018). User Experience Design for Mobile Applications. In Human-Computer Interaction, 10-15.