A presentation of the Volere Requirements Process.

1. 3F
s.a.s di Filippo Fadda

2. Software Development Lifecycle
A software development lifecycle, also known as software
development process, is a structure imposed on the development
of a software product.
Analysis
Quality Gateway
Design
Construction
Staging Deployment
Testing
Production Deployment
Maintenance
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
2

3. Specification Document
Contents
●
Stakeholders
●
Purpose of the Product
●
Users of the Product
●
Commercially available Off-The-Shelf (COTS) Solutions
●
Risks
●
Estimated Costs
●
Use Cases
●
Requirements
–
Functional Requirements
–
Non-functional Requirements
●
●
marzo 2011
Waiting Room
Project Dictionary
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
3

4. Specification Document
Stakeholders
Who are they?
Stakeholders are people who have an interest in the product.
The client is the person who pays for the development of the
product. So the client, maybe in a person that works for it, is a
stakeholder.
The customer buys the product once is developed. You may
already know the names of your customers, or they maybe
hundreds or thousands of unknown people who might some day
put down their money and walk out of the store with the product
under their arm. If you know the customer, or the customers, you
should involve them into the project, because they are
stakeholders.
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
4

5. Specification Document
Stakeholders
Project Manager and Product Manager are the people who
manage the day-to-day project effort.
Developers who will be part of the building effort for the product.
It's not necessary have all the developers involved, but only some
of them.
The marketing department of your company probably needs to be
involved into the requirements gathering process.
Also the legal stuff can be useful. So, for the legal requirements,
you should consult your lawyer.
People who don't want the product should have the opportunity to
express their perplexities.
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
5

6. Project Blastoff
The blastoff is a meeting where the principals stakeholders work
together until they achieved the blastoff's objectives.
Stakeholders are the people who have a vested interest in the
product.
Some of the principal stakeholders are: the client, the main users,
the lead developers, technical and business experts, and other key
people.
The blastoff deliverables lay the foundation for the project. The
blastoff delivers knowledge.
The project blastoff is about knowing. Knowing what you want the
product to do for you, and what it will cost to build it. Knowing the
scope of the work, in order to gather the requirements for the
product.
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
6

7. Specification Document
Purpose of the Product
The second chapter of a specification document deals with the
fundamental reason that your client wants to build a product.
That is, it describes the business problem that the client faces and
how the product will solve that problem.
Maybe the client wants automize a process that is manual, or he
wants reach a new market, but he hasn't the right product for it. Or
simply he wants improve an existence software or build a new
version from scratch.
So, which are the goals of the product? The goals are
determined at blastoff time. You must ensure the goals are
reasonable, attainable, simply stated, worthwhile, and carry and
measurement, so that you can test the delivered product to ensure
that it satisfies the goal.
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
7

8. Specification Document
Purpose of the Product
If the goal does not have these properties, then history
demonstrates that it is unlikely the project will deliver anything
useful.
The goal is used throughout the requirements gathering activity.
Each of the requirements that you gather must contribute, even if
indirectly, to the goal.
Requirements that don't contribute are not relevant, and should be
discarded.
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
8

9. Specification Document
Users of the Product
Users are the people who will interact directly with your product. In
this document section, you identify all the people who might
conceivably make use of the product.
The users are determined when you identify the product boundary
during trawling.
The users determine the usability requirements. That is, you write
usability requirements to suit the characteristics of the users.
The purpose of identifying the user categories is so that you can
understand the work that they do. After all, your product is intended
to help with this work.
Users are the actors will interact with your product features.
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
9

10. Specification Document
Users of the Product
At the starting point is useful make a list of the roles that people
might be play in connection with your product:
●
What are the jobs of the people who might use your product?
●
What other roles might people have?
●
Where will people be when they are using your product?
●
●
marzo 2011
What are the nationalities of the people who might use your
product?
Are there any organizations who might use your product?
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
10

11. Specification Document
Users of the Product
For every users category might be useful write down a their:
●
●
Intellectual abilities
●
Attitude to job
●
Attitude to technology
●
Education
●
Linguistic skills
●
Age
●
marzo 2011
Technology experiences
Gender
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
11

12. Specification Document
Commercially available Off-The-Shelf (COTS)
Solutions
This section of the specification document looks for available
solutions and gives a summary of their applicability to the
requirements.
Is there a ready-made product or a commercial off-the-shelf
software that could be bought?
Can ready-made components be used for this product?
Is there something that we could copy?
Is there some open source project that we can fork?
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
12

13. Specification Document
Risks
All project involve risks.
In this section of the specification you will write down a list of the
most likely and most serious risks for your project.
Against each risks include the probability of that risk becoming a
problem and any contingency plans.
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
13

14. Specification Document
Estimated Costs
The other cost of requirements is the amount of time and money,
the effort, that you have to spend building them into the product.
Once the specification document is complete, you can use one of
the estimating methods to assess the cost, and express this as
monetary amount or time to build.
The important issue is that your estimate is based on metrics
that are directly related to the requirements. If you have
specified the requirements in the way we are going to see, you will
have:
●
●
Number of requirements
●
marzo 2011
Number of product use cases
Estimated number of function points
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
14

15. Trawling for Requirements
Let's trawling
Trawling is a method of fishing that involves pulling a fishing net
through the water behind one or more boats. The net that is used
for trawling is called a trawl.
The boats that are used for trawling are called trawlers. Trawling
can be carried out by one trawler or by two trawlers fishing
cooperatively (pair trawling).
The term trawling comes from Steve McMenamin and it evokes the
nature of what we are doing here: running a net through the
organization to catch every possible requirement.
The trawling analogy is appropriate because the trawlers catch
more fish than they really want. If the skipper catch salmons and
he doesn't want them, he can always throw them back into the
water.
Any inappropriate requirements that get caught up in your net will
be filtered out by the Quality Gateway.
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
15

16. Trawling for Requirements
The Requirements Analyst
The analyst is a translator. He has to understand what the user is
saying about the work, and translate this into a specification for a
product.
The requirements analyst has to inject something new into the
process: his vision of what the product might be.
In other words the requirements are not simply the passive
interpretation of an existing piece of work, but contain inventions
that will make the work easier, better, more interesting and more
pleasant.
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
16

17. Trawling for Requirements
The Requirements Analyst
The analyst observe and learn the work, and understand it from the
point of view of the user.
The analyst must filter the description to strip away any of the
current technology or way of doing things in order to see the
essence of the work, not its incarnation.
Invents better way to do the work.
Record the results in the form of requirements specification, and
analysis models.
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
17

18. Trawling for Requirements
What are Requirements?
Requirements are things that you should discover before starting to
build your product. A requirement is something that the product
must do.
It's fairly obvious that the requirements must be known before
constructing the product.
Design translates the requirements into a plan to build some
physical reality that will, in the real world, do what is required.
The design process needs requirements as input. Designing
without requirements is no more than inventing without
knowing if the invention is useful.
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
18

19. Trawling for Requirements
Discovering the Requirements
It is important to the success of the product that design decisions
are not taken before the relevant requirements are known. Steve
McConnell reports that 60% of error exist as design time.
Users are conscious of some requirements and they will bring
them up early. There are others that we call unconscious
requirements, that are so ingrained into the users' work, that they
have forgotten they exist.
Undreamed of requirements are there because the users do not
realize that they are possible. Whatever the reason, part of the
analyst's responsibility is to bring these requirements to the
surface.
All the requirements must be captured during the trawling activity.
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
19

20. Trawling for Requirements
Models, Mockups and Prototypes
The first part of requirements trawling is observing the work. I
suggest when you are doing this, you are not just a passive
onlooker, but actively understand the work. The most effective
way of doing this is by building a model.
You use models to understand the work. You can't build a model
without understanding the subject of your model, but the modeling
activity makes you ask all the right questions. When the model is
finished, it means that you have understood the subject.
You use models to record the work and to demonstrate your
understanding of it. Most importantly, since the model is a common
language between you and your user, both of you can agree that
you have the identical understanding of the work.
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
20

21. Trawling for Requirements
Apprenticing
Apprenticing is a wonderful way to observe the real work. It is
based on the idea of masters and apprentices. In this case, the
requirements analyst is the apprentice and the user is the master
craftsman. The apprentice sits with the master to learn the job
by observation, asking questions and doing some of the work
under the master's supervision.
To get the user to describe the work, you must not take him away
from his work. Rather, the apprentice sits alongside the user and
receives a running commentary on the work as it happens. Each
actions is explained, and if not clear, the apprentice asks
questions: Why did you do that? What does this mean? How often
this happen? What happens if this piece of information is not here?
So while the apprentice is learning the work by seeing the same
task performed many times, he is also looking past how the user
does the work, to see the underlying essence of the work.
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
21

22. Trawling for Requirements
Interview the Users
Interviewing the users is the traditional approach to requirements
gathering. However, used on its own it may not be the most
effective, because it commonly expects the users to know and to
be able to tell all their requirements. I suggest that interviews are
not the sole method of gathering, instead use them in conjunction
with other techniques.
Mind Maps
We use mind maps all the time. We use them to take notes, for
planning, for summarizing, for exploring ideas. Our brains store
information by making associations. We link each new piece of
information to something, or some things, that we already know.
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
22

23. Trawling for Requirements
Brainstorming
Invention is part of the requirements process. The product that the
requirements analyst specifies should include new and better ideas
for improving the work. Brainstorming is a method for
generating new ideas. Brainstorming takes advantage of the
group effect. That is, you enclose group of bright, willing people,
and ask them to generate as many ideas as possible for the new
product.
Participants in the brainstorm should come from as wide a
range of disciplines. For the moment suspend judgement,
evaluation and criticism. Simply record requirements as they are
generated.
Produce lots of ideas. Come up with as many ideas as possible.
Quantity will in time produce quality.
Write every idea down, without censoring. Ideas disappear faster
than water evaporates unless written down.
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
23

24. Trawling for Requirements
Snow Cards
William Pena, an architect, coined the term snow card. Pena's
architectural firm used white cards to record requirements and
issues relating to buildings they were designing – hence the term
snow.
We use cards when we are interviewing clients and users to record
requirements as we hear them. Initially the requirement is not fully
formed, so we might simply capture the description and the source.
As time as progresses and the requirements become better
understood, the components of the requirement are progressively
completed on the card.
A snow card or shell is a container for an individual requirement.
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
24

25. Trawling for Requirements
Volere Shell
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
25

26. Trawling for Requirements
Requirement Number
Each requirement must be uniquely identified. This reason is
straightforward: requirements must be traceable throughout the
development of the product, so it is convenient and logical to give
each requirement a unique number.
Use Case Number
During later analysis, you will analyze each business event and
use case separately. Thus it is convenient to be able to collect
together all the requirements for that part of the work.
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
26

27. Trawling for Requirements
Requirement Type
There are two main requirement's types:
●
Functional
●
Not-functional
We will see them later.
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
27

28. Trawling for Requirements
Name or Description
This is a brief description for the requirement.
Rationale
The rationale is the reason behind the requirement existence.
It tells why the requirement is important, what contribution it makes
to the product's purpose. Adding a rationale to the requirement
helps you to clarify and understand it. Having this justification of
the requirement helps you to assess its importance when you are
testing for gold plating in the Quality Gateway activity.
Source or Originator
The source is the name of the person who raised the requirement.
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
28

29. Trawling for Requirements
Fit Criteria
The fit criteria are quantified goals that the solution has to meet,
they are acceptance criteria. The tester will use it to determine if
the requirement has been met.
Customer Satisfaction and Dissatisfaction
The satisfaction ranking is the measure of how happy the client will
be if you successful deliver the requirement. The scale ranges from
1 to 5, when 1 means the client is not happy at all, and 5 that is
extremely happy.
Same for dissatisfaction where 1 indicates that the client is
unconcerned about the requirement delivery, and 5 that your client
will be really angry if you don't implement the requirement.
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
29

30. Trawling for Requirements
Dependencies
Dependencies are other requirements that have an impact on this
one.
Conflicts
Conflicts are other requirements that contradict this one or make
this one less feasible.
Supporting Materials
Do not attempt to put everything in the specification. There will
always be other material that is important to the requirements, and
it may be simply referenced by this item.
History
This is the place to record the date that the requirement was first
raised, dates of changes, date of deletion, date of passing throught
the Quality Gateway, and so on.
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
30

31. Specification Document
Use Cases
A use case is a description of an action performed by a user
(or actor) in a software system. The user or actor might be a
person or something more abstract, such as an external software
system or manual process.
Use cases are a software modeling technique that helps
developers determine which features to implement and how to
gracefully resolve errors.
Within systems engineering, use cases are used at a higher
level than within software engineering, often representing
missions or stakeholder goals. The detailed requirements may
then be captured in SysML requirement diagrams or similar
mechanisms.
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
31

32. Use Cases
Specification Document
Main

33. Specification Document
Use Cases
Document Management

34. Use Cases
Specification Document
Community Tools

35. Specification Document
Use Cases list
Document Management
5
Edit Management
Structure Management
5-2
Page Settings Management
5-3
Print Management
5-4
View Management
5-5
Insert Elements Management
5-6
Offline Editing Management
5-7
Text Format Management
5-8
Track Changes Management
5-9
Table Management
5-10
Table Of Contents Management
5-11
List Management
5-12
Form Management
5-13
Link Management
5-14
Image Management
5-15
Hint Management
5-16
Bookmark Management
5-17
Note Management
5-18
Highlight Management
5-19
CVS Management
marzo 2011
5-1
5-20
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
35

36. Specification Document
Use Cases list
Permission Management
6
Customization Management
7
Layout Customization Management
7-1
Toolbar Customization Management
7-2
Menu Customization Management
7-3
Message Management
8
Folder Management
9
Audit Management
11
Advertise Management
12
Users Management
13
Community Partecipation
14
Forum Partecipation
14-1
Poll Managemet
14-2
Pending Content Management
Community Members Management
16
Security Group Management
17
Community Customization Management
18
Community Management
19
Policy Management
20
Root Management
21
Space Management
marzo 2011
15
22
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
36

37. Specification Document
Requirements
Functional Requirements
Functional requirements are things that product must do.
That is, the functional requirements describe functions or
actions that are to be part of the product.
Non-functional Requirements
Non functional requirements are the properties that the
product must have.
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
37

38. Specification Document
Non-functional Requirements' Types
●
●
Usability Requirements
●
Speed Requirements
●
Capacity Requirements
●
Operational Requirements
●
Maintainability and Portability Requirements
●
Security Requirements
●
Cultural and Political Requirements
●
marzo 2011
Look and Feel Requirements
Legal Requirements
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
38

39. Quality Gateway
Check Point
The Quality Gateway is the single point that every requirement
must pass through before it can become a part of the
specification. QG ensures a rigorous specification by testing each
requirement for completeness, correctness, measurability, absence
of ambiguity ad several other qualities before each requirement
can be added to the specification.
Why do we need a gateway? Consider the life that a requirement
leads before it arrives at the QG: the requirement could have come
from anywhere. You have used a variety of trawling techniques to
discover the requirements.
Your concern is to capture all the requirements and not to miss
anything. The resulting potential requirements are in a variety of
forms and states of completion, which makes them difficult to
review. At this stage we call them potential requirements.
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
39

40. Quality Gateway
Using the Gateway
The writing process applies the shell to the potential requirements
and puts them into a consistent form. Now we can call them
formalized potential requirements.
When a formalized potential requirement arrives at the QG it
should be complete enough to undergo the tests to determine
whether it should be accepted into the specification or excluded. If
it is excluded, then it is returned to its source (originator) for
clarification, revision or discarding.
To pass through the QG and be included in the specification, a
requirement must pass a number of tests. Those tests ensure
that the requirements are complete and accurate, and do not
cause problems by being unsuitable for the design and
implementation stages later in the project.
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
40

41. Quality Gateway
Testing Completeness
The requirements shell is a container for an individual requirement.
The shell identifies the component parts of a requirement. You can
use the shell to help you test whether a requirement is complete.
Are there any missing components?
Test each component of the requirement and, from the point of
view of each stakeholder, ask: it is possible to misunderstand this?
There are, however, times when the components are not all
necessary. For example, sometimes the Description makes it
obvious why the requirement is important. In that case there would
be no point in writing the Rational. Sometimes there are not
Supporting Materials and so on.
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
41

42. Quality Gateway
Testing Traceability
To make sure each of your requirements is traceable it must have:
●
●
The type of requirement
●
Reference to the Use Case that contain the requirement
●
Requirement's dependencies
●
References to other requirements that are in conflict
●
marzo 2011
A unique identifier
Consistent use of terminology
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
42

43. Quality Gateway
Testing Fit Criteria
The fit criterion is a measurement of the requirement that enables
the testers to determine, without recourse to subjective
judgements, whether the deliver solution meets, or fits, the
requirement.
Is it essential that each requirement has a fit criterion. Any
requirement that has not one must be considered incomplete.
Reject any requirements that don't have a valid fit criterion.
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
43

44. Quality Gateway
Viable Within Constraints
Do you have the technological skills to build the requirement?
Have you the time and the money to build the requirement?
Is the requirement acceptable to all stakeholders?
Do any partner applications or the expected work environment
contradict the requirement?
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
44

45. Quality Gateway
Customer Value
The customer satisfaction/dissatisfaction ratings attached to each
requirement indicate the value that the customer apply to it.
The satisfaction rating is a measure of how happy the customer will
be if you successful deliver an implementation of the requirement.
Instead the dissatisfaction rating measures the amount of
unhappiness the customer will feel if you don't successfully deliver
the requirement.
Gold Plating
The term gold plating comes from gold plated bathroom taps.
Some people like to have gold plated taps. The water doesn't come
out of the gold pated tap any better than it does from a chrome
plated one. The difference is that the gold plated tap costs more.
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
45

46. Quality Gateway
Requirements Creep
Requirements creep may refer to requirements that enter into the
specification after the collecting process is supposed to be
finished. The product in fact keeps evolving. However, there is
stage of the project when you decide that you are going to go
ahead and build the product. The requirements that happen after
this stage are the ones considered to be requirements creep.
Requirements creep has gained itself a bad name, usually
because of the disruption to the schedules, and the bloated costs
of product delivery.
Firstly, most creep comes about because the requirements
were never gathered properly in the first place.
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
46

47. Specification Document
Waiting Room
Waiting room is for requirements that cannot, for one reason or
another one, be part of the initial release of the product.
Your users and client know that the requirements are not forgotten,
but merely parked until they can be incorporated in a future release
of the product.
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
47

48. Specification Document
Project Dictionary
Names are important. During the blastoff you begin to collect and
record the names that are used by the project. Each project or
product has names that are particular to it. This is the terminology
that you are trying to capture along with an agreed meaning.
Record the names in the project dictionary section of the
specification document. This is a glossary that serves as a
reference point for the project. It's impressive how many
misunderstandings are caused when there is not a central glossary
available.
This recording process never finish. During the trawling phase
or when you collect new requirements, you will discover new
names, that you must add to the project dictionary.
marzo 2011
3F s.a.s. di Filippo Fadda – Piazza Carlevaro, 6/1 – 15067 Capriata d'Orba (AL)
48