Category: Requirement Engineering

system requirements document in story form example

system requirements document in story form example

the humble story of Tafe course enquirer


A long time ago, there was this man TAFE who was sitting on a bench. You can see the sadness in his eyes by his troubled past.


“I’m sorry TAFE we know what you’ve done for us, but this is the end. We are going public; we will look for other people as well”


Voices of the past echoes in his head. After everything he has done, after everything he has given, in the end it didn’t matter.


“for almost 2 centuries, my family have given 500,000 enrolments, 1000 courses and this is what I get? This is not fair!”


He shouted in to the air hoping people will hear his agony but no one was there to listen. He laughs off… like a maniac, wondering his eyes in the disbelief of change. He knows that he has to go private now that things have changed. But was not confident he can keep up with the competitions around. With their shiny promises to lure people in. He gets up from his chair and wonders through the park where he hears a sudden voice.


“looks like you’re having a bad day TAFE”


He looks around and sees an old man sitting at a bench shuffling tarot cards on his hands. He moves to the bench and sits next to the old man. He does not know why but somehow this Oldman has irresistible charm.


“pick three cards”


The old man said. TAFE upon hearing this picked three cards.


As he looked at the first card with a sword crossing.

“Hmm… looks like you are worried about competitions”


As he looked at the second card with an anchor.

“with your way of doing things you don’t seem to have much chance on people asking you questions, finding out what you can offer or keep in contact”


As he looked at the third card with a wall.

“It looks like your customers need to go through a wall of obstacles to find what they need through you”


TAFE was stunned. The cards were spot on about the worries he has been having.

“pick another three cards”


TAFE’s hands automatically moved towards the cards. As he tried to pick the cards the old man grabbed TAFE’s hands.

“maybe I’ll just show you”


A vision went through TAFE’s eyes. He did not understand anything until he looked at the calendar. TAFE was in the future. He seemed to have done well for himself. The way he is doing things now seems way different from how he did things before. TAFE was curious how, he quickly jumped in to his computer and searched for his website. When he accessed it, he saw something amazing. The search engine has been replaced so that people can search it by keywords like google. After coming this far he got more curious so he searched favourite course. There he found a subscription button. He pressed the button and an email popped up on his phone showing his subscription.



He shouted, he then browsed some more and found an enquiry button.


“what’s this?”

TAFE asked himself. He clicked the button and it was a text message box.


“this is it?”

TAFE was surprised, the system was stripped to the bare minimum that he didn’t think was possible. He then submitted an enquiry and got a respond in record time. TAFE was marvelled at his own system when suddenly he hears a voice at the door.


“enjoying yourself, TAFE?”

The old man was standing on the door, only this time he looked familiar as if like an old friend.


“some fortune teller you are… who are you?”

The old man answered

“I am your future, no more will we bounded by EBS and its shackles of documents. No more we will be bound by long and boring process. No more we will be scared of competitions…”

The old man spoke and he stared into TAFE’s eyes and said.


“my name is TAFECourseEnquirer”

At that time TAFE woke up from his bench. He noticed he never moved around the park in the first place. It all seemed like a dream.


“it doesn’t have to be a dream”

He muttered to himself as he stood up and walked on eyes full of determination.

7 stages of an ongoing process: Requirements Engineering

7 stages of an ongoing process: Requirements Engineering

The primary measure of success of any software is the degree to which it meets the purpose for which it was intended. Requirements engineering is the process of discovering that purpose by identifying customer needs for the system and the constraints under which it is to be developed and operated.

1. Groundwork: Requirement Engineering is often known as a front-end activity. However, variety of contexts, including market-driven product development and development for a specific customer should also be considered. The identification of a suitable process for requirement engineering and the selection of methods and techniques should also be carried out before collecting requirements.

2. Requirement Elicitation: Identify the stakeholders and understanding the system boundaries. Various techniques like interviews, questionnaires, observation, document review, group workshops and brainstorming are useful in requirement gathering. One simply needs to select the technique or techniques most suitable for the elicitation process.

3. Requirement Analysis and Feasibility Study: Analysis is a repetitive activity in the software development. This phase gives the answers of questions how, what, who, why and when and also test the feasibility and accuracy of existing requirements. Initial design like use-cases can be prepared as a work product of this process.

4. Define Scope: Identify the events inside and outside the system, the information that flows between the system and the actors outside the system and the major functions included in the system.

5. Communication: Documenting requirements at each and every stage of requirement engineering is very crucial for communication. Writing formal and informal documents like Minutes of meeting (MoM), Vision and scope document, System Requirement Specification (SRS) document and taking the approval from stakeholders ensure validation and avoid ambiguity as well as conflicts at the later stages.

6. Change Management: Requirements change throughout the SDLC. How these changed requirements should be accommodated in the software is very challenging task. Each proposed change should be evaluated in terms of existing requirements and architecture so that the trade-off between the cost and benefit of making a change can be assessed.

7. Requirement Traceability: Whatever requirements have been gathered and agreed should be traceable in the final software product to be delivered. Requirements should be reviewed and checked at the each phase of SDLC