← Schedule



EXERCISE #2 AN SRS DOCUMENT

Developing a Software Requirements Specification (SRS) Document for an Art Catalog System

By Sandino Vargas-Pérez


This exercise will help you practice developing an SRS document for a client's system. An SRS defines what the software system will do and how it is expected to perform. It acts as a bridge between your client's needs and your development process. A good SRS ensures everyone on the team is on the same page—developers, testers, clients, and users.

Exercise Description:

In this exercise, your team will act as a software development group working with a client (the same professional artist, Nube, from Exercise #1) who has requested a system to manage and showcase their artwork. The goal of this exercise is to create a brief, but comprehensive Software Requirements Specification (SRS) that defines what the system should do, who the users are, and how it should function.

You will be provided with a general client description and initial project idea. It will be your responsibility to perform requirements elicitation (based on what you and your team did for Exercise #1), define user needs, and formally document the functional and non-functional requirements of the system.

Your final deliverable will be a complete, professional SRS document suitable for guiding a development team through the design and implementation phases.

NOTE: SRS documents can take many forms an styles. You remember the SRS document in DQ #3 aboout a mental health system (Mentcare). Here's another example of an SRS document that applies Use Cases and UML diagrams to describe their system.

Learning Outcomes:

By completing this assignment, you will be able to:

  • Identify and organize software requirements using input from a hypothetical client.
  • Apply requirement elicitation techniques to translate client needs into clear system specifications.
  • Differentiate between functional and non-functional requirements in a software system.
  • Create a structured, professional-quality SRS document using standard software engineering conventions.
  • Collaborate effectively as a development team to analyze, write, and refine system requirements.
  • Critically reflect on the challenges of defining software systems before implementation.

New Client's Request Summary

Your team just receive an email with your client's new request for the Art Catalog system they want you to develop:

Hello again, Nube here. I contemplated a bit more what I really want for the system, and I need one that helps me display and manage my collection of paintings and photographs. I want a place where I can upload high-resolution images, add titles, descriptions, dimensions, and prices. I also want to organize my work by categories and have a way for visitors to view, browse, search, and filter my art. Some pieces will be for sale, so I'd like to include pricing and a way for users to contact me if they're interested. I don't want to deal with platforms like PayPal or other external e-commerce sites, they tend to charge too many fees. I also want the system to allow visitors to leave comments on my pieces and "like" their favorite artworks. I think it would be cool if they can create and account to be able to do this and create, for example, favorite lists with the pieces they like the most!

SRS Document Structure

For the purpose of this exercise, you will build your SRS document following the outline below (this outline is written and defined with real-world developers in mind, so you will see words like "organization", "corporate", "business", and so on. You should be able to adapt those definitions to the classroom, your small team, and your fictional client):

  1. Introduction
    1. Purpose
      This section explains what software system the document is about. It should name the product, mention the version if relevant, and clearly state what part of the system is covered in the SRS (whether it's the whole system or just a specific piece of it.)
    2. Intended Audience and Use
      Identify the individuals or teams within your "organization" who will use the SRS and describe how they are expected to use it. This typically includes roles such as developers, testers, and project managers, but may also involve stakeholders from other departments like leadership, sales, or marketing. Clarifying this early on helps prevent confusion and reduces rework later in the project.
    3. Product Scope
      What are the benefits, objectives, and goals you intend to have for this product? This should relate to overall business goals, especially if teams outside of development will have access to the SRS.
    4. Definitions and Acronyms
      This section lists and explains any key terms, acronyms, or abbreviations used in the SRS so that readers won't be confused. If the project uses a lot of technical or specialized terms, you can include a glossary at the end and mention it here.
  2. Overall Description
    1. User Needs
      This section explains who will be using the system and what they need from it. Think about different kinds of users—like administrators, customers, or even people who just read reports—and what they expect the system to do for them. Try to understand their roles, goals, and why the system matters to them. If the person buying the product is different from the one using it, include both.
    2. Assumptions and Dependencies
      This section lists what you're assuming to be true when designing the system. These might include things like the system running on certain devices or using specific technologies. Writing these down early helps avoid confusion or problems later if those assumptions turn out to be wrong.
  3. System Features and Requirements
    1. Functional Requirements
    2. External Interface Requirements
      External interfaces, such as the UI or APIs that connect the software to other business systems. You can skip this section if you think you won't need it.
    3. Non-functional Requirements

Stage 0: Develop the Introduction

For this portion of the SRS document, your team will think about the purpose of the document, intended audience and use, scope, and definitions and acronyms. Because you are developing this document in less than a week, you will limit the system to only being able to manage users and artwork, browsing artwork, and user interactions with the art pieces.

NOTE: If you need to role play with ChatGPT you can "feed" the new client's request so that it can create a "memory" and provide you with acceptable answers. Remember to start your prompt with: Let's role-play. Pretend to be a client ... and then insert (and edit so that the prompt can flow as natural as possible) the client's request above.

Stage 1: Overall Description

In this section of the SRS document, you will describe each possible user of the system (you already know there is an artist and there are visitors of the artist's catalog). You will also define dependencies and assumptions for the systems and user interactions. For example, if the system will be a web application, then an assumption might be: "The system assumes users have internet access."

Make sure you declare assumptions that you think will help the system work correctly.

Stage 2: Develop System Features and Requirements

For the purpose of this SRS, your team will only focus on the following functional requirements:

  • User Management: Users can register, log in, and manage profiles, etc.
  • Artwork Management: Users can upload images, enter descriptions, set prices, categorize artworks by type, medium, and availability, and edit or delete existing artwork entries, etc.
  • Artwork Browsing and Search: Users can search artworks by title, category, medium, or price range, and can view details of individual artworks, including high-resolution images, etc.
  • User Interaction: Users can comment and or favorite artworks and receive notifications about new uploads, etc.

When you write these categories of functional requirements, make sure you thoroughly describe everything that the user and the system needs to fulfill it. Also, "Users" should be substituted for the actual type of user that is intended to perform the activity (from the ones you identiofied ).

For non-functional requirements, develop the following categories:

  • Performance
  • Security
  • Usability and Responsiveness
  • Compatibility
Make sure that you and your team understand what these categories are about and which non-functional requirements are needed for your system within these categories.

Report Preparation and Formatting

Your team needs to prepare the SRS document following the structure in Document Structure section. The report structure should contain the following:

  • Presentation Page, similar to this one
    Presentation page for SRS Document
  • All the components shown in the Document Structure section.

Use of A.I. Assistance

You can use ChatGPT or Deepseek to help your team develop the SRS document, making sure that you are using it as a tool for aid and NOT as a replacement of your intellectual capabilities. The following is an example of asking ChatGPT for help developing the "Artwork Management" functional requirements:

Prompt:
I'm developing an SRS document for an Art Catalog system, and I need to think about functional requirements for the "Artwork Management" feature of the system. Can you help me figure it out?

ChatGPT Reply:
Absolutely! Let's break down the "Artwork Management" feature of your Art Catalog system into a clear list of functional requirements. These describe what the system must do to support artists (or admins) in uploading, editing, organizing, and displaying their artwork.

Artwork Management - Functional Requirements

Here's a structured list of functional requirements you can use or adapt in your SRS:

1. Upload Artwork
1.1. The system shall allow an artist to upload one or more image files representing an artwork.
1.2. The system shall support common image formats (e.g., JPG, PNG).
1.3. The system shall validate image resolution and file size before upload.

2. Enter and Edit Artwork Metadata
2.1. The system shall allow the artist to enter the following details for each artwork:
  - Title
  - Description
  - Medium (e.g., oil, watercolor, digital photography)
  - Dimensions (e.g., 24” x 36”)
  - Date of creation
  - Price (optional, if the item is for sale)
  - Availability status (e.g., For Sale, Sold, Not for Sale)
2.2. The system shall allow the artist to update or correct any of the above fields after initial submission.

...

Do not just copy & paste the answers given by ChatGPT or Deepseek, you will format them and paraphrase them or use them as a starting point to develop your own, following the style of your SRS document.

Prepare a PDF version of your document and submit to Kit.

Report Submission to Kit

Once the document (in PDF) is ready for submission, One member of the team will submit the report and invite the other team members to collaborate:

  1. The team member uploads the PDF.
  2. Once the document is successfully uploaded, the team member clicks the I Worked With Someone Else option and "Invite" the rest of the team members.
  3. The rest of the Team member accepts the invitation.

DUE DATE: Friday of Week 3, by 11:59 p.m.

Evaluation

Exercise #2 is worth 10 points. The following rubrics describe the criteria I will use to evaluate your team's work:
TBD

  • Presentation Page [0.5 point]
    • SRS opens with a presentation page similar to the one in "Report Preparation and Formatting" section with project title, author names, organization (should be Kalamazoo College), and date created. 0.5 pts.
  • Introduction [2 point]
    • Clearly and concisely summarizes the purpose of the software described in the SRS. 0.5 pts.
    • "Intended Audience and Use" is well defined 0.5 pts.
    • The "Product Scope" section clearly states what are the benefits, objectives, and goals for the software. 0.5 pts.
    • Sufficient "Definitions and Acronyms". 0.5 pts.
  • Overall Description [2 point]
    • "User Needs": users are identified and described correctly. 1 pt.
    • "Assumptions and Dependencies" have been identified and clearly stated. 1 pt.
  • System Features and Requirements [4 points]
    • Requirements elicitation & user needs demonstrate thoughtful analysis of the client's request.1 pt.
    • Functional requirements include clear, complete, and well-organized descriptions (via use cases, user scenarios and stories, or natural or structured language, and so on). 1.5 pts.
    • Specifies relevant and realistic non-functional requirements (e.g., usability, performance). 1.5 pts.
  • Organization [1.5 point]
    • The document is clearly organized with appropriate headings, readable formatting, free of significant grammar or spelling errors, and consistent style use (not a mixture of everything). 1.5 pt.

LATE WORK: Late submission is allowed for this assignment, but a -10% penalty will be applied to the total grade.



← Schedule ↑ To the Top