Software Engineering Series (Part-I)
Requirement Phase…Let’s see what you need.
So,It’s the start of my first series on Medium and i thought of doing it about thing that i’m actually studying these days. It’s going to be a series and just hold tight cause this will include almost everything you’ll need to know about Software Engineering.
I know this field will evolve continuously but this series will give you the basic idea about terms that you’ll face during your journey of software engineering. Also, please if you find anything wrong or misleading just let me know, it would really mean a lot to me.
Note : This series is for someone like me that means it’ll be the deconstruction of everything you’ll find out there.
Let’s start this series by talking a bit about Software Engineering.
Software Engineering : Software Engineering is the branch of engineering related to the application of the principles and techniques of computer science,engineering and mathematical analysis to the development of a software.
So,what does that actually mean.It’s actually all about implementing some of the terms you’ll face in this series.
It’s the procedure to develop a software efficiently on time and in a manner that it’s progress could be tracked and error if occurred could be corrected while minimizing all the risks.
I think i summarized all possible parts in the above definition. Software Engineering (sometimes referred as Software Development )involves different phases of life cycle :
- Requirement Analysis
We’ll cover all these phases in this and the coming series.
We’ll start with the Requirement Analysis.
It involves the following terms that you’ll face while studying about it.
1 . Requirement Elicitation : It is the practice of collecting the requirements of a system from users customers and stakeholders .Elicitation(the fact that good requirements can not be just collected from the customer.)We need intelligent requirements aligned with the product.
Practices: Interviews, Questionnaires, User Observation Workshops, Brainstorming, Use Case Role Playing and Prototyping.
There are 3 problems related to elicitation :
I .Problems of Scope : No limits when it comes to the users as they can go in any direction while giving requirements misaligned from the product .
II.Problems of Understanding : They may not have the proper understanding of the product.
III.Problems of Volatility : Users and their uses may change too frequently.
Quality Factors to judge our elicitation:
4.Consistent use of templates
6.Analysis of changes.
2 . Requirements Analysis : These task encompasses those determining the needs or conditions to meet for a new or altered product, avoiding conflicts, analyzing, documenting, validating and managing software or system.
In short, figuring out all the important requirements that push your product in the direction you want it to evolve.
The activities involve 1. eliciting 2. Analyzing 3. Recording
3 . Atomic Requirements : A requirement that is measurable, testable, traceable and detailed enough to define all aspects of a need without further breakdown.
To understand consider all those requirements that are complete in themselves without any different requirement fulfilling them to be able to behave as a requirement.
ex: Suppose you’re building a music player .
Your requirements :
1.To be able to search and like my favorite music.
2.To be able to delete and play my favorite songs.
So, did you get what’s wrong in the above requirements.Yes, you just naively wrote your expectation but it could turn out to be a wrong product.
Let’s see what changed:
1.To be able to search songs and like my favorite songs.
2.To be able to delete songs and play my favorite songs.
The first requirement states to search and delete your songs. And you definitely don’t wanna do that. So,I hope it’s clear why it’s important to have atomic requirements. Rewritten like this, search and delete to search songs and delete songs are clearly different activities and support different user goals.Otherwise you’ll end up deleting your favorite songs(:P).
4 . Requirements Attributes : The value assigned to each attribute that help to organize, analyze and prioritize the requirements in a project.
5 . Requirements Reviews : It is a manual process that involves people from client and contractor organization. They check the requirements documents for anomalies and omissions.
Just a process to make sure everything is on point and everything is as planned.
6 . Traceability Management : The ability to describe and follow the life of a requirement in both a forward and backwards direction i.e. from its origin, through its development to its subsequent deployment and use and through periods of ongoing refinement and iteration in any of these phases.
Complete path or journey of all the requirement in all of its forms.
7 . Management of Requirement Portfolio : It is the centralized management of the process, method and technology used by project managers and project management offices (P.M.O) to analyze and collectively manage current or proposed project based on numerous key characteristics.
Just to keep track of all the requirements and all the details related to the requirements.
So, It’s all for this part of the series and to excite you, here it is.
Please, point out my mistakes if you find any.
Find it if you can.😉
Every week there will be new terms regarding software engineering in specified sections. So, make sure you follow curiosity journey and software engineering section to stay updated.
Appreciate this, if it helped you by sharing it within your community and leave a comment below with a clap on the bottom right corner.
It would mean the world to me
Also, get in touch with me @adityad85 on Twitter and Instagram.
Take The First Step 🖖.