Lecture 7
Domain and Inverse Requirement
Objective:
Provide explanations and examples to make student understand what domain requirements are?
To know what inverse requirements are?
Examples as a Food For Thought
-The hospital management system should support the check-in and check out for IPD (In Patient) and oPD Out patient Department
- The GL system should have the ability to post Double entries
- The GL system should have the provision of maintaining chart of accounts
- System will keep claim records & losses reserves, Financial Transactions and Claim expense records
- Supporting associate agents at the policy level setup commission due based on written premium, on invoicing or on premium payments and generating agent statements
Carefully go through the above examples and you will find terms that you won’t understand. This highlight two important aspects
1. People belonging to the field of software engineering must know about other domains
2. Some of the requirements may not be mentioned or explained explicitly because the people belonging to that domain may consider them implicit or understood.
Such requirements are considered as domain requirements. Following are some characteristics of domain requirements
1. They may be functional or non functional
2. Reflect the characteristics and come from domain
3. Sometimes not explicitly mentioned
4. Absence of these can cause significant dissatisfaction
5. Sometimes pose strict constraint on system.
Inverse Requirements
• Inverse requirements can be functional and non functional
• When a customer specifies that something must not be done. For example, User ID should only contain digits.
Lecture 9
User and System's View of Requirement
Objectives
• To understand what User/ Customer’s View of requirement should represent
• To Understand what System and Contract view of requirement should contain
What user’s/customer’s view of requirement should contain?
• Should include a description of user’s need, functional and non functional requirements, expectations and constraints
• Explained at a higher level of detail
• Specified inform of natural language
• May include diagrams which mostly are drawn in such a way that there is no need to learn any modeling language to understand them.
• Should not include technical terminologies of Computer Science/ IT domain incase, especially incase where readers are not IT literate
• Detailed discussion on system requirements should not be included
• Design aspects should not be included at all.
What System’s/Contract view of requirements should contain?
• Functionalities, services and constraints explained in detail
• Technical details included
• This must be complete and consistent because incompleteness may lead to failure
• Used by designers and developers as a starting point for design etc.
• Should be understood by customer and development team, especially if they are IT literate.
• Used to develop initial architecture
• Documented in natural language and may contain diagrams developed in modeling language like UML.
• May contain information regarding architecture in two situations
o The client has specified some design and implementation constraints
o There is some interoperability with an existing system and some architectural constraints due to that will be included
Some Concerns Regarding Requirements
• Very expensive to change after they have been finalized
• Sometime requirements are not clear because the human languages lack clarity
• Sometimes team is not sure about the category in which a requirement falls.
• Sometimes requirement amalgamation is faced where a number of requirements are specified in single line.
• A single line can be perceived differently by readers
• A single line can be phrased differently
