Showing posts with label Requirement Engineering. Show all posts
Showing posts with label Requirement Engineering. Show all posts
Friday, 13 November 2020
Friday, 26 June 2020
To understand the concept of Software Architecture you should have knowledge and concept of what is Architecture.
When you here this word, At the most simplistic level, you think about the overall shape of the physical structure. The word Architecture put the image of building into your mind most of the time but not simple building the most beautiful and well engineered building.
Why this happen?
Why this happen? Because just making a building is not the goal of arch Making a building by keeping all technical aspects in mind and dealing with them is the goal of architecture.
It is the way in which the building fits into its environment and meshes with other buildings in its vicinity.
It is the degree to which the building meets its stated purpose and satisfies the needs of its owner.
The architecture is not the operational thing.
Rather, it is a representation that enables you to:
- analyze the effectiveness of the design in meeting.
- consider architectural alternatives at a stage when making design changes is still relatively easy.
- reduce the risks associated with the construction.
The concept of Software Architecture:
I hope now you would have the basic mind set about what is the Architecture. Its time to move towards the concept of software architecture.
Architecture serves as a blueprint for a system . It provides an abstraction to manage the system complexity.
It defines a structured solution to meet all the technical and operational requirements, while optimizing the common quality attributes like performance and security.
IEEE defines architectural design as “the process of defining a collection of hardware and software components and their interfaces to establish the framework for the development of a computer system.”
Software Architecture Styles:
Data centered architectures : A data store (e.g., a file or database) resides at the center of this
architecture and is accessed frequently by other components that update, add, delete, or otherwise modify data within the store. Existing components can be changed, and new client components
added to the architecture without concern about other clients. Client components independently execute processes.
Data flow architectures: This architecture is applied when input data are to be transformed
through a series of computational or manipulative components into output data. A pipe and filter pattern has a set of components, called filters ,connected by pipes that transmit data from one component to the next.
Call and return architectures: This architectural style enables you to achieve a program structure that
is relatively easy to modify and scale. two arch. styles are relative to this call and return architecture style.
Main program/subprogram architectures . This classic program structure decomposes function into a control hierarchy where a “main” program invokes a number of program components that in turn may invoke still other components.
Remote procedure call architectures . The components of a main program/subprogram architecture are distributed across multiple computers on a network.
Object oriented architectures The components of a system encapsulate data and the operations that must be applied to manipulate the data. Communication and coordination between components are accomplished via message passing.
Layered architectures: A number of different layers are defined, each accomplishing operations that progressively become closer to the machine instruction set. At the outer layer, components service user interface operations.At the inner layer, components perform operating system interfacing. Intermediate layers provide utility services and application software functions.
Why the architecture is important?
The answer to this question would be clear to you till know but still let me tell you some key points which will summed up why the software architecture is important.
Three key reasons that software architecture is important:
- Representations of software architecture are an enabler for communication between all parties (stakeholders) interested in the development of a computer based system.
- The architecture highlights early design decisions that will have a profound impact on all software engineering work that follows and, as important, on the ultimate success of the system as an operational entity.
- Architecture “constitutes a relatively small, intellectually graspable model of how the system is structured and how its components work together”.
Video Lecture in Hindi Urdu For the above notes.
Tuesday, 14 April 2020
Design and Implementation constraints with example
These are also a type of requirments but a little bit confusing to understand some time because it is not like Inverse Requirements, Domain requirements or Organizational requirment it is something which come out of other requirments and you identify it using the paremetr you will have in a couple of minutes to identify if it is design and implementaion constraint or not.
The Parameter to identify design and implementation constraints:
The parameter is simple and you can take it as the defination of Design and Implementation constraints as well. i.e. The requirment which put some kind of restriction on your development process weather it is coming from the Domain or Organizational requirment you can identify it as this is the Design and implementation constraints.
Lets go towards the Example
You are making a website for any organization, Now you are a complete software development company and you have lots of options to develop a website you may chose php, Asp.NET, Python or any other language.
But the company impose a constraints on you that you must make a website using Php because they have lots of other tools and website working on the same platform so it will be easy for them to integrate it with other.
These are the design constraints; You may get these from any kind of requirements e.g. Domain Requirements or may be Inverse requirements etc.
Video Lecture on the Topic : design and implementation constraints
Slides presented in the lecture:
Monday, 13 April 2020
 |
| Organizational Requirements in Requirements engineering |
Organizational Requirements in Requirement Engineering
Organizational requirements are also the requirements same like the domain requirments and inverse requiremtns we always talk about functional and non-functional requirments and forget these things which are most important and should be tackled in we manners.
Organizatioal Requirmaents are the the requirments which we directly get from the organization to implement on the software.
First of all you should have knowledge about the domain requirments so you can better under stand it spare some time to read about domain requirments.
For Example: A Shop Owenr want you to develop the software which will deal with the sales and purchase operation of the shop.
The Domain of the software is POS. The software will inherit the all features which a POS should have those are the domain Requirments actually but beside those may be you want to make some customization to those domain requirments, may be you want to have an option in the sale section of the software that if someone make the shopping of 10,000 or more than this He should get 20% discount on total bill. Because this is the rule of organization (shop) so this is not something comming from the domain this is something coming from the organizational rule so this will be oranizational Requirment.
Watch a video lecture on the topic Organizational Requirments in Software Engineering
Thursday, 9 April 2020
 |
| Domain Requirments in Software Engineering | Requirement Engineering |
Domain requirements in software engineering examples
What is domain requirement?
These requirements come from the domain in which a system fall.
What is Domain?
Domain is simply the area where your software belongs to.
Let's take example of a “Bike” domain:
If any vehicle belongs to the domain of the bike it will definatley inherit few requirments from the bike domain i.e. That vehilce should have two tires. If a vehicle have four tire you can't say it is a bike because it do not full fill the reqirments or say core requirments of the bike domain.
Let suppose you are making a site to sale products online the domain of that website will be e-commerce.
You are making a software for shop domain of that software will be POS(Point of sale).
That means your site gona inherit the requirments from the e-commerce domain what are those requirments which your site will inherit?
There could be many requirments but let me take simple and basic one i.e. your site should have a shopping cart and payment options settings as your site fall under the e-commerce domain so these are the core requirements of the e-commerce domain.
In the 2nd example we are using the POS domain to clear the concepts, now if you are making a software for the shop, store or a mart the domain of that software will be POS so you have to inherit and keep the POS domain requirments in the software, those requirments are your POS should have option to maintain the sales and purchases, can you have a shop software without this option? No, you can't have that is because this is the core functionality of the software working for a shop and its is the Domain Requirments of that software too.
Video Lecture on the topic: domain requirements in software engineering in hindi
Wednesday, 8 April 2020
Inverse Requirments in Software Engineering | Software Requirement Engineering
Software requirment engineering the sub-field of Software Engineering and the field about which we never care a alot. When ever we talk about the Software Requirement engineering we talk about the Function and Non-Functional requirments most of the time.
We never pay attention to further types of requirments there are other requirments as well
- Inverse Requirements
- Domain Requirments
- Organizational Requirments
Sometime the software are of general type which the client want you to develop so most of the things are pre understood that these things will be part of the software so if someone cut of some requirements He will define that in inverse form.
For Example: POS is the common software and developers know what are the things a POS should have.
But if the client want you to reduce a future He will define it in inverse form.
He may say POS should not have the discount option.
May be the Client is open to usage of any color in the Software UI but hates the usage of specific color so He may say don’t use this color.
Video Lecture on the Inverse Requirements:
Tuesday, 5 November 2019
What is software quality? What are the factors in which software quality depends? this videos is good for software developers, software users so they can analyze after watching this video if the software they are using is good in quality? if the software they are developing is good in quality? No tools are required just basic things to check software quality analyze by yourself your own software.
case tools are most discussed thing is software engineering, this video will tell you what are the case tools in actual what are the categories of case tools and how they provide ease in working. The video is providing the answer to following questions: 1) What are case tools? - Answer at 1:582) CASE stands for? - Answer at 1:26 3) what are the categories of CASE tools - Answer at 2:084) some examples of CASE tools - Answer at 2:55 It is humble request to like our video and subscribe our channel: https://youtube.com/SoftwareEngineering
Brief: Project Scheduling: An activity in which you decide how you will divide the project into the smaller tasks. What is Milestone? It can be any like your software is consist of three functions the first function is consist on 1st two tasks so you will achieve it after completing first two tasks. Resource Estimation: If your Project is divided into 6 tasks let suppose so you should have knowledge what kind of and how much resources are required to complete specific task. A good Rule: Make estimate as nothing will go wrong and then add few more days to the final estimation as if goes something wrong so we have at least some extra days. For more better understanding don't forget to watch video.
Key points : ◙What are Software Requirements? Description of services which a software will provide to the end user. ◙What is the difference between user and end user? User: of any software will be the company for which you developed the software. End the person who is actually using the software sitting in front of the computer. ◙What are functional requirements? In one sentence “What the system should do.” ◙What are Non-Functional Requirements? How a system should behave while performing the operations.
Brief: This video is about how to make Software Requirement Specification document in Software Engineering. It is the complete lecture, at the end A real SRS is also shown by the teacher to make the concept more clear. ===================================================== Link to Functional and Non-Functional requirement Lecture: https://youtu.be/02AouF6wXz4 Link to Gantt Chart Lecture: https://youtu.be/k8y6Uotw8go ===================================================== What is SRS? A documents use to describe the behavior of the software System, Functional, Non-Functional requirements of the software system. Users of the SRS? Development Team Maintenance Team Clients Technical writers Contents of the SRS are also well define in the Video. Real SRS Document is also shown by the teacher.
Brief: This video tell you how to use interaction matrix to find out the conflicts or overlaps in the Requirements of the project.
Thursday, 31 October 2019
Software Requirements: Means the requirements in the software i.e. a complete description of what the software system will do.
The software requirements are divided into different sub type i.e.
- Functional Requirement
- Non-Functional Requirement
- Domain Requirement
- Inverse Requirement
- Design & Implementation constraints
Let me define and explain each and every type one by one
- Functional Requirement: In functional requirements we actually define the actual functionalities for which we are developing the software system. In short functional requirement actually define what the system will do. If we get in details the functional requirements actually define what will be the reaction of system for the particular input and what will be the behavior of the system in different conditions.
If our system is showing any kind of abnormal behavior we will also put that behavior in the list of functional requirements and in the exceptional handling.
Changes are part of software development but we should try to make functional requirement complete & consistent. When the software is under-development customers and developers completely focus on functional requirements because these are the actual functions the software has to perform when it will release.
Example of Functional Requirement:
Example 1:
Suppose we are making a system to perform mathematical operation and there is a requirement
“The system should solve the quadratic equation using the formula i.e. x = (-b+sqrt(b^2 – 4*a*c))/2*a”
So we will put this requirement into the list of functional requirements.
Example 2:
Let’s take a look at another example suppose we are making a vehicle database management system which will store all the records of vehicles and assign a unique ID to every vehicle through which we can access the records of the vehicle. Now in this example “Every vehicle should be allocated a unique ID so we can access the record of that vehicle” so this is the functional requirement.
Critical review of the Functional requirements:
- All functional requirements are not always same in the sense of level of details some have small details while other requirements have deep details.
- If we take a closer look to the example one in which we discuss the quadratic equation the functional requirement is not defined in detail.
It is not define what will happen if the value of “a” becomes 0. i.e. (a=0)
- When requirements are incomplete like in “example 1” people may miss interpret the requirements and this may become cause the poor quality of software.
- Non-Functional Requirements: Non-functional requirements are not limited to the specific function of the system. We implement these to the whole system.
For Example: Suppose we want to achieve the performance we will try to achieve the performance in the whole system not only in the specific function of the system so that is why the performance is in the non-functional requirement.
Same like performance, the reliability, security, maintainability are also the non-functional requirements. We cannot ignore the non-functional requirements as well as functional requirements; they are also important part of the system. As I try to clarify each of my concepts by relating the concept with any solid example so the best example to show the importance of non-functional requirement is the aircraft Reliability check. Till now according to our discussion “reliability” is non-functional requirement but an aircraft cannot be marked as saved if it is not reliable so this example shows how many important non-functional requirements is.
These Non-Functional requirements are further divided into the categories
1) Product Requirements 2) Organization Requirements 3) External Requirements
Product Requirements: It tells people what a product should do. For the product requirements we write the product requirements documents and mention all the requirements there.
Example: Suppose we develop a website which allow “one hundred thousand” clicks per minute so we will mention it as a Product requirement that the system allow one hundred thousand clicks per minute.
Organizational Requirements: Organization requirements mean the priorities and preferences of organizations are considered first.
Suppose we are developing software for any organization, the organization has some priorities and rules we will first follow them in the software.
Example: There are lots of standards which we can follow for the development of software but for which organization we are developing the software use always a specific standard so we will follow that one for that organization because this is the requirement of organization.
External Requirements: These requirements affect the software or its development process externally. Usually came from outside or from the people who will get affected by the software.
Example: Suppose an organization is developing a system which will keep the all personal record of the employees. So employees must demand that the system should secure enough and data should be accessible by the system administrator when needed only so these requirements will be consider as external requirements.
Some critical review on Non-Functional Requirements: Non-functional requirements reflect the general goals of the system but some time it becomes difficult to differentiate between functional requirements & non-functional requirements because of the nature of the system. Let me clarify my point with the example.
Example: Till now according to our knowledge Security is a non-functional requirements but if we are making a system for the bank which deals with the money transactions now for this system security will becomes the main priority and off course the client will also demand the security so we here it will become the functional requirement.
We should try to mention the non-functional requirements clearly the best way to write something clearly is mentioning it in quantitative manners.
There are high chances of confusions in non-functional requirements as we know that these Non-functional requirements are coming from different stakeholders so conflicts can be arise into the requirements.
- Domain Requirements: The domain means area where the software system going to work some domain are pre-define suppose if we are making an online shopping website so its domain will be e-commerce. So some requirements will come from the domain like in case of e-commerce domain we will have some already understood requirements like “System should provide secure system to client for making system” so like this the requirements came from the domain of the system are known as domain requirements.
Domain Requirements can be both functional and non-functional requirements; these requirements are not well explained it is the job of requirements engineers to find out these requirements. One cannot ignore these requirements because these are sometime functional and sometime non-functional kind of requirements and absence of these requirements can create heavily dissatisfaction in the developed system.
- Inverse Requirements: These are very simple these requirements explain what the system should not do. Most of the time client explains the requirements in inverse form. Suppose a client visit to you He want you to develop a POS(Point of sale) for his shop he asked you do not you red color in the interface now actually he is saying you cannot use red color but you are open to use other colors so these kind of requirements are known as inverse requirements.
- Design & Implementation Constraints: These are the requirements or we can say the constraints which we apply on the development process.
Suppose a designer is designing the interface and the client or stack holders ask him for the specific design so now the designer is limited to keep the design under the constraints which the stake holders define.
One more example to clarify the concept of this kind of requirements is, suppose a client ask a developer to develop a website now the developer can develop a website using php, asp, WordPress or any other platform but if the client give his requirements, He asked to develop a website using Asp platform so now the developer is bound to develop the website using asp with Microsoft .NET framework.
There is also another view of requirements although the other requirements are derived from the main categories of functional and non-functional requirements but play an important role in to the development of well-established system we will discuss them in to the next articles.
Requirement Prioritization Techniques And Need
Being a requirement engineer, It is a tough job to take decision what is important for the client, what is most important for the client and what can be ignore for sometime in the system. off course clients involvement is an important part so the client should remain involve in the overall decisions, No matter how much a client is involve some time the condition arises when it becomes difficult to prioritize the requirements because some time the client want the working software with most important features with in no time and you have to full fill this requirements under the constraints provided by client e.g. Budget, time, reliability level and etc.
So how you can do this?
Software engineering is a growing field new methods and approaches are getting add into it day by day, But the good news is we already have some approaches to solve this problem.
When we go to buy a Smartphone, there are lots of smartphones available in the market with tones of features some smartphones have good camera but do not have good battery timing some time a smartphone provide you good battery timing but may be there is lack of a good camera so you have to compromise your beautiful selfie. Now this is the point you will take a prioritization based decision either the camera is important for you or the battery timings matters for you because you are a working guy and don’t have enough time to plug the phone for 3 hours. So if you are a working guy you will compromise the camera and go for long lasting battery you take the decision and prioritize the battery on the basis of your need. Same kinda approaches can be used in Software requirement engineering to give the client a comfort of requirement prioritization.
Things to Note first when prioritizing the requirements :
- May be the most important functionality will not be the first prioritization because it is expensive and the lack of budget is the client side problem.
- Possibly there will be more than one Software Stake holders and different stakeholders have different priorities sometime.
- Keep in mind the simple rule, As a requirement engineer you have to prioritize the requirement under the constraints by the feedback of stakeholders
- The most important point to note is the requirement prioritization process is iterative development approach may be the thing which is 1st priority in one iteration will be the 2nd priority in next iteration so it is important to keep checking.
Techniques of Requirement Prioritization:
- Negotiation Technique : In this technique requirement engineer will work with the stakeholder, clients and all other who will be the user of the software collect the requirements, get feedback on the requirements negotiate with customer e.g. what you want to provide the first, or agree them what is better for them to get in start of the software.
- Quantitative Technique : In this technique Requirement Engineer should perform an analysis on the basis of quantities e.g.
- What is the budget of client for first feature needed in software?
- In how much time the client want the working software?
- What are the financial benefits?
- What are the risks?
- How much level of risk we can bear on the current level?
After getting answers of those all questions the wining requirement should be the first priority and all stakeholders will also satisfy on that.
The Requirement Prioritization approach is applicable the in the agile development methodology, it is beneficial for the client to get working software as soon as possible and it is good as well for the developing organization.
the methods discuss above can be beneficial to the requirement engineer in the efficient requirements prioritization process. Video Lecture on the Topic:
