Software Development Requirement Analysis | explicit and implicit requirements | JAVA Simplified 04

JAVA Simplified 04 Requirement Analysis | explicit requirements and implicit requirements

Software engineering requirement analysis and requirement gathering example

Outline
-----------------------------------
#1 Intro: 0:00~1:56
#2 Explicit requirements: 2:01~2:57
#3 Implicit requirements: 2:58~7:37
#4 General case: 7:38~8:57

 

#1 Intro (0:00~1:56)
In the last couple of lessons, you might have learnt to use Eclipse to create a project and write a little bit code, and learnt some basic syntax and rules in Java programming language.

But honestly you can't do much when all you know is HelloWorld. Fortunately, you can still move forward a big step. Now the most accessible, yet one of the most important things you can do is to analyse requirements. Remember, please analyze the requirement before writing a single line of code. At least try it. It saves you from a lot of future disputes. This is also the reason why I spare an entire lesson on this even before teaching you the details in the programming language. Plus, if you can do it well, you can even ask another programmer for help, without you having any computer science knowledge. 

So, what do you do with a document that states the requirement? There is no perfect answer. But me, personally, will pay attention to numbers, logic and potential problem and risk. Computer program needs the numbers to do calculations and makes decisions with logics. Some information is clearly stated in the document. But others not. This leads us to explicit requirements and implicit requirements. 

Clients provide us only with the explicit requirements in the form of documents. Software engineers should be able to identify potential problems or risks which clients obviously always can’t. But implicit requirements are gathered from experience and proper understanding of the application. Often time, business users would say, ‘We thought that this was going to be delivered…it is an Implicit requirement!’.

In this video, from an example, we will try to find out the explicit requirements and as many implicit requirements as possible. 

#2 Explicit requirements (2:01~2:57)

Explicit requirement, is the one that is clearly stated in the document...

#3 Implicit requirements (2:58~7:37)

Hidden requirements are referring to the implicit requirements...

#4 General case (7:38~8:57)
In real life, requirement document can be as short as this example, or can be longer; can simple as this one, or can be way more complicated; can give you more specific and explicit requirements, or can be as flawed as this. If someone gives me such a document, I would definitely reject it. Even if I decide to make it happen somehow, I would ask tons of questions, like what I've been doing here. Questions after questions. One question leading to another question. Another question leading to more questions, until I have enough explicit requirements.

But anyway, no matter what other people give us, let's have our key techniques and skills ready. Identify the numbers, the logic, and the potential risk and communicate with whoever gives you the requirement. 

This lesson introduces to you the skills for analyzing a requirement document and focuses more on technical skills. But apart from that, it would be better to have a good understanding about the existing system if you are asked to modify it. This is when experience plays a critical role. Above all, you'll find good communication and good relationship is even more critical to customer satisfaction. 

Hope this helps.