MSE | CMU
Quick Guide on The Requirements courses at MSE | CMU 17–626/627
This is all about the requirements course at CMU
What if you were told to cook a dish for a party you had never cooked before what do you think your first step would be to do?
Well obviously you would order the dish but if we imagine cooking as software development then you would look at its recipe.
When we are handed a new project the first phase of action is to make sure we understand what is expected from us , our deliverables. This can be translated as fixing our requirements and that is what the courses offered are all about. It tries to answer one single question
How do we understand and represent the requirements of a project professionally?
Now if you are planning to enrol or have already enrolled in the MSE program then this is a free online guide for you to know about the course.
And if you are a student who has completed this course just go down and like the article as an appreciation , you already know about this and can help increase the engagement of this article :) .
Lets begin.
The variations
First we must address the elephant in the room that is the difference between the Requirements for Embedded systems (RES )course and Requirements for Information systems (RIS ) course.
Personally I had taken the embedded systems course even though my background is very cloud heavy and I found it pretty helpful.
So if you are a student in the scalable systems track your only option is the information systems course , if you are in the embedded track your only option is the embedded systems course.
If you are in the professional track you get an option to choose. I will take this opportunity to clear up a misunderstanding , many students believe that you need to have knowledge of embedded systems for the RES track. That is not true based on the following points
- You only have to give ideas about the embedded systems you want to use like temperature sensor , humidity sensor etc. There is no need for you to go deep dive into it.
- The instructors and TA and aware of your background and if you are not from a ECE/EEE background. Moreover the details of the embedded systems is not a focus of the course and makes a tiny portion.
That being said please take my words on the information systems course with a grain of salt (if you plan to cook instead of order) as I cannot advocate for it having not taken the course. You must conduct your own research on the course beforehand irrespective of which track you belong to.
The Requirements Document
The entire course is spent on building this document every week. You think of an idea revolving around embedded systems like a start up and have to develop a professional requirement document for everything your start up has to offer.
Remember there is NO CODING , NO DEMOS , NO IMPLEMENTATION for the ideas you give except that they must be believable to some extent to build a requirement document.
The main focus of the course is to play the role of a requirements engineer , take a bunch of backbone requirements and transform it to a professional requirement document.
The start of Attributes
The start is followed by defining attributes of the course
Functional Requirements: define specific behaviours or functions that a system must perform. They describe what the system should do, typically in the form of inputs, processes, and outputs
Quality Requirements: describe how well the system performs its functions. They specify criteria used to judge the operation of a system, rather than specific behaviours
Quality Attributes: properties of a system that indicate its overall quality or effectiveness. They represent categories of quality requirements like reliability , performance etc.
You will have to come up with a bunch of these for your start up product and there are rules to writing these if you want to maintain a professional standard which is focused a lot on the course.
Personas and People
I think this is one of the best parts of the course. Personas as defined by google
Personas are fictional characters that represent different types of users for a product, service, or brand. They are created based on research to help designers understand users’ needs, goals, and behaviours.
Personas are useful for any company if they want to build a new product , it might be one of the first steps a company takes before even building a product. It is useful because
- Help teams understand and empathize with their customers
- Provide deep insight into customer goals, behaviours, and motivations
- Aid in making design decisions and prioritizing features
As part of the coursework you will learn how to develop personas and will be evaluated for them and have to develop your requirements to meet the demands of the personas.
Operational Scenario and Usecases
Operational Scenario
Ahigh-level description of how the system will be used in its intended environment, offering context and helping stakeholders visualize the system’s operation.
They typically include a sequence of steps that outline the interactions between users, the system, and its environment.
You will have to develop different scenarios which demonstrates how your system will work its interactions.
Use cases
They focus on more specific interactions between actors (users or external systems) and the system to achieve particular goals. They describe the system’s behaviour from an external perspective, detailing the steps and variations involved in accomplishing a task.
Use cases are particularly useful for capturing functional requirements and for developing tests.
You will have to develop use cases for your product which will be accompanied by flowcharts which demonstrates how your product works.
A piece of advice is to make nice flowcharts which look appealing to the eye.
Validation and Traceability
Traceability
Traceability refers to the ability to establish relationships between different artifacts in the development process, particularly between requirements and other work products.
- Ensuring completeness: By tracing requirements forward into work products, you can identify missing requirements or implementations.
- Verifying origin: Backward tracing allows you to verify the source of requirements and work products to avoid new scope entering.
This is something you will have to do from the beginning of the course and will be evaluated upon. You can also use this for other projects like I used it for the final document in Quality Assurance to give a trace for all our pull requests , issues and requirements.
Validation
The process of evaluating whether a system or software satisfies its intended purpose and meets user needs.
- Real-world testing: It may involve testing the system in its intended operational environment.
- Acceptance criteria: Validation typically uses predefined criteria to determine if the system is acceptable.
This is done towards the end and is like how would you test your product for each use case.
General Advice
- Professional Document: Try to make the document as professional as possible , on proof reading it should look good to you.
- Discuss: One thing I did was discuss with few of my peers with ECE background about my features. The instructors and TA’s are there to help you but you can take the help of the embedded systems students.
- Give good feedback: At one point you have to review some one elses document. Don’t try to team up with them and plan to get less feedback for changes.
- Participate in class: Try to get your doubts cleared in the class by discussing them. It is helpful to get the view of the other students and instructors. Also you get participation points for the same.
Closing Thoughts
This course revolves around how well you define your requirement document. The process is very long and takes considerable effort but is professional.
The concepts taught here will be useful for the Practicum projects next year for professional and non professional students.
How useful will it be not sure , while working on a project you will think about requirements in a different sense in a good way but will probably not follow such a long process.
