Month: March 2016

7 stages of an ongoing process: Requirements Engineering

7 stages of an ongoing process: Requirements Engineering

The primary measure of success of any software is the degree to which it meets the purpose for which it was intended. Requirements engineering is the process of discovering that purpose by identifying customer needs for the system and the constraints under which it is to be developed and operated.

1. Groundwork: Requirement Engineering is often known as a front-end activity. However, variety of contexts, including market-driven product development and development for a specific customer should also be considered. The identification of a suitable process for requirement engineering and the selection of methods and techniques should also be carried out before collecting requirements.

2. Requirement Elicitation: Identify the stakeholders and understanding the system boundaries. Various techniques like interviews, questionnaires, observation, document review, group workshops and brainstorming are useful in requirement gathering. One simply needs to select the technique or techniques most suitable for the elicitation process.

3. Requirement Analysis and Feasibility Study: Analysis is a repetitive activity in the software development. This phase gives the answers of questions how, what, who, why and when and also test the feasibility and accuracy of existing requirements. Initial design like use-cases can be prepared as a work product of this process.

4. Define Scope: Identify the events inside and outside the system, the information that flows between the system and the actors outside the system and the major functions included in the system.

5. Communication: Documenting requirements at each and every stage of requirement engineering is very crucial for communication. Writing formal and informal documents like Minutes of meeting (MoM), Vision and scope document, System Requirement Specification (SRS) document and taking the approval from stakeholders ensure validation and avoid ambiguity as well as conflicts at the later stages.

6. Change Management: Requirements change throughout the SDLC. How these changed requirements should be accommodated in the software is very challenging task. Each proposed change should be evaluated in terms of existing requirements and architecture so that the trade-off between the cost and benefit of making a change can be assessed.

7. Requirement Traceability: Whatever requirements have been gathered and agreed should be traceable in the final software product to be delivered. Requirements should be reviewed and checked at the each phase of SDLC

Andrew Foo

Andrew Foo

Greetings fellow humans!

This technology loving soul is devoted to coming up with solutions to all the challenges that your business may present.

I come from a hospitality background with more than 10 years of experience, during my time in hospitality I was presented with challenges on a daily basis that needed a working and proven solution. Being a fast-paced environment, I was required to work under pressure from start till end of each work-day.

I started working in the IT industry in 2015 and thrived on the new challenges that my new role in IT Support had presented. I found passion in solving problems relating to Web Development, RDBMS Database Structure, Software Support, and AD-HOC software solutions to end user problems.

In my short time as a IT Support Officer I have developed the following skills which include Cisco CCENT, PHP, C#, VB, Microsoft AD, Microsoft Exchange, Microsoft IIS, Microsoft SQL Server, mySQL server, and VMWare.

As a Business Analyst, I am driven to deliver the best possible solution that your business requires. A solution that is scalable, efficient and driving your business with minimal effort.

Andrew Foo.


Scrumban: A different way to be Agile

Scrumban: A different way to be Agile

If you’ve been working in software development any time recently, you’re probably more than familiar with the Scrum—a methodology that comes with both pros and cons.  Now,  there is a  different way to approach project planning and management that some projects may find useful. It’s called Scrumban.

But first, what is Scrum?

Scrum is an iterative and prescriptive process for building software using the Agile methodology. A development team plans and commits to completing a certain amount of work in a certain time period called a sprint. At the end of the sprint, the team reviews the work with a product owner. They then hold a retrospective to analyze their processes during the sprint, and determine what can be improved next time.

Scrum can be an effective tool for introducing teams to Agile. Its more rigid structure provides a framework of understanding that is far easier to grasp than the loose nature of  Kanban might be for teams used to rigidly planned waterfall-style projects.

The daily standup, planning, review, and retrospective meetings are excellent touch points for periodic checking in with the work that is happening and reviewing with stakeholders. The retrospective itself is the crown jewel of the Scrum framework, and is what enables teams to focus on continuous improvement, or Kaizen.

One of the primary motivations for moving a team to Scrum is to get away from the often restrictive and inefficient processes of the waterfall model. In this model, there is frequently too much time spent on planning and designing before any work begins. After that, teams find themselves unable to respond to change later in the project as the developing and testing proceeds. All of this is why waterfall is a sub-optimal process for software development.

But look at the makeup of a typical Scrum sprint:

  1. Team plans the work that will be worked on over the next sprint.
  2. During planning, teams try to design as many features as possible, so that they can more accurately estimate what they can complete during the Sprint.
  3. During the Sprint, the team develops and then tests their user stories.
  4. At the end of the Sprint, the Product Owner reviews the work completed, and decides which of the stories are shippable and ready for production.

What does this mean? Scrum is a series of miniature waterfall projects wrapped up into iterations called “Sprints.” This is a push-based system, where another solution would be to use a pull-based one. Enter Scrumban.

What is Scrumban?

Scrumban is a pull-based system, where the team no longer plans out the work that is committed to during the planning meeting, and instead continually grooms the backlog. The same Scrum meetings (planning, review, and retrospective) can and should still take place, but the cadence of them can be more context-driven. The real key to moving to Scrumban, though, is ensuring that work in progress (WIP) is still limited.

Work-in-progress limits, not Sprints. With Scrum, the amount of work that is ongoing is limited by the Sprint time commitment. But in Scrumban, with no specific time commitment, the team must limit itself through the use of WIP limits on columns within their task board. The goal is always to move tickets in a flow from left to right on the board. If too many issues are in progress, the team is at risk of not finishing anything to high quality standards. Instead, there should be a maximum number of tickets allowed per column. If the number of tickets in that column ever exceeds the maximum, the entire team should swarm onto that column and help move tickets on. This should happen no matter what functional role a team member fills.

Planning meetings. These should take place as often as they are needed. When the team is unable to regularly pull stories off the top of the backlog at their normal pace, a planning meeting is necessary.

Review meetings. Reviewing work with clients and customers is the only way that development teams can get the feedback necessary to properly adapt what they are working on. Clients tend to prefer that these are held at a regular cadence.

Retrospective meetings. These can vary when held, but a general rule of thumb is to hold a retrospective after every review. This is the most useful part of the Agile process and should be given the proper place for that.

Standup meetings. Standup meetings in the Scrum world follow a simple pattern. The team takes 15 minutes and each person says, a) what he/she did yesterday, b) what he/she is working on today, and c) what is blocking any of that work.

In practice, this boils down to redundant statuses that recount information available on the team’s task board. For Scrumban, a more effective method is to refocus on the flow of tickets on the board. That same pattern of yesterday/today/blocked can be transferred to the tickets themselves—the group moves through each column and briefly discusses each ticket and what is necessary to move that ticket rightward on the board. This provides far more context to the team and informs everyone of any major architectural or design decisions.

Metrics. Metrics can certainly be useful, but they are often abused by managers and business stakeholders who want to unnaturally simplify a complex process into a one-dimensional number. Velocity, the amount of story points a Scrum team completes in a single Sprint, is such a metric that incentivizes lower quality at the end of a Sprint as a team scrambles to finish every last story they committed to. When the number fluctuates, as is common with a newer team, the stakeholders begin to question the outputs of the team, and even the effectiveness of Agile itself.

Instead of velocity, a useful Scrumban metric is cycle time. This is the length of time a ticket takes to complete, measured from when it is first began. Over time, a statistical analysis of all tickets in the project can yield a mean cycle time and standard deviation. This can be a useful planning tool at a macro level, as it is trivial to add up the number of stories and multiply by mean cycle time.

Noora Mirzakhani

Noora Mirzakhani



Hi there, being a member of Magnificent 11 team, I am feeling super awesome! It is my pleasure!

We have a competent combination of professionals, ready to help our customers with any kind of problem!

Telling more about myself, I am Noora Mirzakhani , professional Business Analyst in Industry and Engineering oriented projects, My study background is MBA and Electronics Engineering and I have been working in different business and industries for more that 8 years. also, using my managerial skills in business area, I’m an entrepreneur, running my own business, and like helping people running and managing their small and big businesses. My analytical mind and management abilities help me to manage different challenges and work effectively in both self managed and team based situations.I have keen interest in learning new concepts and knowing what is going on beyond my immediate discipline.

I am passionate about communicating with people, nature, travelling, bush walking, yoga, photography and whatever makes me enjoying every single second of life! my favorite quote is this:

You must be the change you wish to see in the world”

Working as business analyst, I can use my experience, talents and professions to make benefit for people, companies, and whoever needs help in boosting their business success!

So, any kind of issue you have at your business now, all you need to do: come to us, count up to 10, relax, and just see Magnificent 11’s magic! all done!




SCRUM | 3 essential roles

SCRUM | 3 essential roles

There is three essential roles for scrum to work successfully

As discussed in my previous post “Introduction to SCRUM” the scrum team has a different composition than a traditional waterfall project, which include three specific roles: product owner, scrum master, and the development team or also called delivery team.

SCRUM 3 Roles

Scrum teams are cross-functional, “the development team” includes developer, testers, designers, and ops engineers in addition to developers and sometimes the customer.
The product owner

Product owners are the champions for their product. They are focused on understanding business and market requirements, then prioritizing the work to be done by the engineering team accordingly. Effective product owners:

Build and manage the product backlog
Closely partner with the business and the team to ensure everyone understands the work items in the product backlog
Give the team clear guidance on which features to deliver next

However let’s keep in mind that the product owner is not a project manager. Product owners are not managing the status of the program. They focus on ensuring the development team delivers the most value to the business. Also, it’s important that the product owner be an individual. No development team wants mixed guidance from multiple product owners.
The scrum master

Scrum masters are the champion for scrum within their team. They coach the team, the product owner, and the business on the scrum process and look for ways to fine-tune their practice of it. An effective scrum master deeply understands the work being done by the team and can help the team optimize their delivery flow. As the facilitator-in-chief, they schedule the needed resources (both human and logistical) for sprint planning, stand-up, sprint review, and the sprint retrospective.

Scrum masters also look to resolve impediments and distractions for the development team, insulating them from external disruptions whenever possible.

Part of the scrum master’s job is to defend against an anti-pattern common among teams new to scrum: changing the sprint’s scope after it has already begun. Product owners will sometimes ask, “Can’t we get this one more super-important little thing into this sprint?” But keeping scope air tight reinforces good estimation and product planning–not to mention fends off a source of disruption to the development team.

Scrum masters are commonly mistaken for project managers, when in fact, project managers don’t really have a place in the scrum methodology. A scrum team controls its own destiny and self-organizes around their work. Agile teams use pull models where the team pulls a certain amount of work off the backlog and commits to completing it that sprint, which is very effective in maintaining quality and ensuring optimum performance of the team over the long-term. Neither scrum masters nor project managers nor product owners push work to the team (which, by contrast, tends to erode both quality and morale).

The scrum team

Scrum teams are the champions for sustainable development practices. The most effective scrum teams are tight-knit, co-located, and usually 5 to 7 members. Team members have differing skill sets, and cross-train each other so no one person becomes a bottleneck in the delivery of work. Strong scrum teams approach their project with a clear “we” attitude. All members of the team help one another to ensure a successful sprint completion.

As mentioned above, the scrum team drives the plan for each sprint. They forecast how much work they believe they can complete over the iteration using their historical velocity as a guide. Keeping the iteration length fixed gives the development team important feedback on their estimation and delivery process, which in turn makes their forecasts increasingly accurate over time.

Kuzhanthai Velu Vasudevan

Kuzhanthai Velu Vasudevan


A dynamic and highly committed  IT professional  with over 10 years of experience in IT Operations and Development of Applications in Datawarehousing . I have extensive experience consulting with various business and IT areas within different Clients.

I have considerable documentation experience that includes producing business requirements, technical/functional specifications, end user and operational support documentation, test summary reports. My high attention to detail enables me to produce high quality documents.

Information is all about Data . Data Analysis is my key area of Interest.

I bring my experience and knowledge on Business Analysis to make your life easier. Magnificent 11 is a team of Business Analyst who can help you to grow up your business.

Paul Rigney

Paul Rigney

Paul Rigney

I have over 20 years experience as an Analyst Programmer working for Telstra IBM and myself. I have vast experience on UNIX systems and the following programming languages c, c#, php, awk ,sed , shell, PL/SQL. My expertise in business analysis my ability to communicate with both the business and developers because I worked on both these sides of the business.

Purvil Acharya

Purvil Acharya

Allow me to Explain why I am the zest you need when life gives you lemons.

I strongly believe that I can help you with whatever solutions you may require, as my work ethic is extremely strong. I am determined and enthusiastic towards whatever task I have to complete. I approach everything with positive and an open mind. outstanding IT skills. My organization skills are excellent due to my previous experiences as they often required me to sort out several data inquires and also work under strict deadlines. This allows me to plan out my tasks so I can execute it effectively and efficiently. My hardworking and perfectionist behavior ensures that every task is done to the best quality. Being the youngest member of out marvelous team I try to adapt with all specialties , as I have yet to develop my own.


  • Technical Proficiency

Type of PC(s) – Windows based

Operating Systems – Windows 10 / Android

Most recently read non-fiction book – Big Data

A skill I’d like to acquire within next 6 months – Data Analysis / Technical Analysis.

  • Highlights of Expertise

 Troubleshooting/Resolution

 Resource Management

 Quick learner

  • Certifications

 Cert III in I.T Digital media ( Australian college of business)

 Advanced Diploma – I.T Business Analysis  ( TAFE Ultimo)

  • What I like to do outside of I.T / Who I am

 Sports – Tennis , Cricket

 Acting / Filming

 Tech Savvy

Purvil Acharya ,


Joseph Stefano

Joseph Stefano

Good day, this is your pilot speaking. Your journey with us will be smooth with me designing your solutions and managing your risks.

Our team of highly talented and diverse individuals will take care of your strategic and tactical needs to remain agile and competitive in the modern landscape.

So just sit back, relax, and enjoy the ride.

You’re in good hands.


– Joseph Stefano

B.E., B.Sc., Adv. Diploma of Business Analysis.