The document discusses different types of requirements for software systems such as domain requirements, inverse requirements, design and implementation constraints, and user/customer and system contract requirements. It also covers topics like what happens when requirements are wrong, how requirement engineering begins and ends, and defines UML and the requirement engineering process.
The document discusses different types of requirements for software systems such as domain requirements, inverse requirements, design and implementation constraints, and user/customer and system contract requirements. It also covers topics like what happens when requirements are wrong, how requirement engineering begins and ends, and defines UML and the requirement engineering process.
The document discusses different types of requirements for software systems such as domain requirements, inverse requirements, design and implementation constraints, and user/customer and system contract requirements. It also covers topics like what happens when requirements are wrong, how requirement engineering begins and ends, and defines UML and the requirement engineering process.
Domain requirements are special rules and needs that come from the speci c eld where the system will be used. Ignoring these can make people unhappy, and they can be strict. Some words used might be confusing if you don't know the eld well.(functional and non) EX: 1-in sales business ,negative commissions are not allowed .developers need to be careful to avoid calculating negative commission in system. 2-in banking ,most accounts don’t allow spending more money than available (overdraw).but some accounts have exceptions and allow limited overdraw.
2)What is inverse requirements and give example?
Inverse requirements explain what the system is not supposed to do. Some people nd it easier to describe their needs by saying what they don't want the system to do. EX: system should not use the color red in the user interface when asking for input from the end-user.
3)What is design and implemtation constraints and give example?
Design and implementation constraints are like special rules for designers. They have to follow these rules when making a system. These rules limit their choices and can also a ect the people working on the project, like the team members available. EX: 1- The system shall be developed using the Microsoft .Net platform. 2-The system shall be developed using open source tools and shall run on Linux operating system
4)What are the another 2 views of requirements and explain?
1-User/customer User or customer requirements are statements that describe what the system should do and how it should work. They are written in a way that people without technical knowledge can understand. It's important to keep them separate from detailed system requirements in a document. 2-system contract (complete and consistence) System contract requirements are detailed descriptions of what the system should do and any limitations it has. They help create a contract and guide designers and developers in building the system. These requirements are written in a way that technical sta and the development team can understand. They focus on "what" the system does.
5) What is UML? Is a speci cation language, which has become the standard for modeling requirements .
6) What happens when requirements are wrong?
Wrong requirements lead to late, unreliable systems that don't meet customer needs. This causes loss of time, revenue, market share, and customer trust. ff ff fi fi fi fi fi 7)How requirement engineering begins and ends? Begins=There is recognition that a problem exists and requires a solution .A new software ideas arise. Ends =With a complete description of the external behavior of the software to be built
8)Draw requirement engineering process (input/output)?