Recitation 9: Software Specifications

Effective communication is incredibly important when developing real-world software. Real-world software is very complicated, and often involves multiple developers and clients. A software developer is responsible for creating software requested by a client. For example, a restaurant owner (i.e., the client) may contract a web developer to create a website for their business. From a developer’s perspective, understanding the needs of the client is as important as writing code – if the developer creates software that doesn’t meet the clients needs, the client will not be happy with it! In this activity, you will play the role of both software developers and clients.

You can complete these activities either individually or with a partner.

Preparation

When preparing for recitation, you will play the role of a client. You should describe some kind of software that can be created in Snap. Ideally, the software should be simple enough that it can be created in about 30 minutes. Don’t actually write code for the software! Instead, describe the software in writing and with sketches. This document is referred to as the “software requirements specification” (SRS). For example:

Print out your SRS document, and bring it to recitation.

At Recitation

At recitation, you will swap your SRS document with another team. Each team will develop the software described by the other team. In the real-world, the communication and development process would take place over multiple weeks. For this activity, you will adhere to a strict timeline to approximate the real-world experience.

• \(T_0\) to \(T_0+5\) minutes: Time for students to arrive, and for the instructor to explain the activity.
• \(T_0+5\) to \(T_0+10\) minutes: Five minutes for teams to pair with other teams, to explain their SRS documents, and to ask any clarifying questions.
• \(T_0+10\) to \(T_0+35\) minutes: Teams have 15 minutes to start developing the software for their client. You must work independently – no communication with the client is allowed until the next check-in!
• \(T_0+35\) to \(T_0+40\) minutes: Teams have five minutes meet with each other. They should demonstrate their progress and ask clarifying questions. If it seems like there won’t be enough time to finish the software, try to scale down the project. What is the minimum set of features that could be delivered that the client would still find acceptable? If you think you will finish ahead of schedule, are there additional features the client would like?
• \(T_0+40\) to \(T_0+55\) minutes: Teams have 15 minutes to continue developing the software for their client. You must work independently – no communication with the client is allowed until the next check-in!
• \(T_0+55\) to \(T_0+60\) minutes: Time-up! Teams should share links to the projects they developed with their clients. Clients should test the software thoroughly, to see if it does what they described.

Note: The instructor should clarify the timeline by writing it on the board, filling in the time offsets with real times. The instructor will announce when each transition should occur.

Note: If there are an odd number of teams, a team can be formed of two individuals. They should decide on which SRS they want to swap with another team.

Note: If you cannot attend recitation, you should find another team using Piazza, and complete the activity as described.

Submit

Ensure that all teammates submit to Moodle. Everyone should upload a PDF containing a filled-in version of the template shown below:

Template

• Team member name(s): Peter Story
• Our team’s SRS document:

• Link to the project the other team developed: LINK
• Link to the project my team developed: LINK
• Reflections on the process:
  • Did the other team successfully implement the software you described? Mostly: they made it so whenever you drag a block onto the hole, the hole says “You win!” It would be better if the game only said “You win!” once all the holes have been filled.
  • Did your team successfully implement the software described by the other team? I think so: I couldn’t find a costume that matched what they described, but otherwise my game does everything they described.
  • What went well? The games were simple enough, I think we had enough time to finish them.
  • What challenges did you encounter? The other team’s SRS didn’t describe things very clearly, so it was important to clarify when we talked.
  • Thoughts on how this activity could be improved in the future: