SPONSORS:






User Tag List

Thanks Thanks:  0
Likes Likes:  0
Dislikes Dislikes:  0
Results 1 to 10 of 10
  1. #1
    Points for Confirmed Friends
    Guest

    Operational Requirements

    I had talked about controlled requirements at http://www.qaforums.com/Forum15/HTML/002224.html but I think this topic is a little bit different. I'm curious if anyone has done operational requirements. Specifically, I'm curious if controlled requirements are considered the same as operational requirements. (If that's the case, I guess this post should've gone in the linked post.) The only thing that I know must differ is the way operational requirements are written out as opposed to how controlled requirements are written out. That much I got from the literature. I'm also curious how some people tie this in with what are called non-functional requirements. I'm not a fan of that term but I know I have to accomodate it at some point.

    Any help would be appreciated.

    ------------------

  2. #2
    Senior Member
    Join Date
    Dec 1999
    Location
    Chicago,Illinois,USA
    Posts
    2,537
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Total Downloaded
    0

    Re: Operational Requirements

    <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by AitenB:
    I'm curious if anyone has done operational requirements. Specifically, I'm curious if controlled requirements are considered the same as operational requirements.<HR></BLOCKQUOTE>

    Operational requirements (in the strict sense that I assume you mean) can be part of controlled requirements but controlled requirements do not have to be operational requirements. So it pays to keep that in mind. For example, situational requirements are a type of controlled requirement but are certainly not an operational requirement (again, in the strict sense of the term).

    <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>The only thing that I know must differ is the way operational requirements are written out as opposed to how controlled requirements are written out ... I'm also curious how some people tie this in with what are called non-functional requirements.<HR></BLOCKQUOTE>

    As you say, I am not a fan of the term "non-functional requirements" either. In my opinion, good QA professionals do not use this terminology at all. Rather they speak of the quality and cost attributes that apply to the functionality. (This is something of what I mentioned in the "Controlled Requirements" thread that you provided the link to.)

    Anyway, more to the point: the focus on operational requirements, from the levels of control and basic processes that I discussed in the "Controlled Requirements" thread, is on quantification. If we want operatioanlly qualitative requirements, we need to define an operational language for specifying them and an operational scale of measure for measuring them. That is, strictly speaking, what operational requirements are about. The rationale is easy to see. Many statements of requirements are vague in the sense of not being quantified. Such statements are often called "non-functional requirements" - that term we both agree we dislike. For my part, I dislike the term because it evades the issue of what unquantified statements are. In general, they are quality requirements. They are not functional requirements (what the system shall do); they are not cost requirements (which resources the system shall use); they are they not design ideas (what we will do to make the system meet its requirements). They are also not general constraints (which create a demarcation around permitted and non-permitted areas of requirements and design).

    Let us consider a non-IT based example. Consider an unquantified objective like "lose weight." A statement of requirement for this might be something along the lines of: "I want to lose weight." Obviously that is an unquantified statement. Now consider another way of writing this by using operational language. We need a specific requirement, a meaning to the requirement, a scale, a metric, and qualifiers. If you have those things you can specify "I want to lose weight" (your general requirement) in an operational manner. So, let us write this as such:

    WEIGHT:
    Meaning: to lose enough weight so that I do not look or feel overweight
    Scale: weight in relation to average weight for height, age, and sex expressed as a percentage
    Meter: weighing scales compared to tables of normal weight
    Past: [last year, me] 5%
    Must: [end of this calendar year, me] 25%
    Plan: [end of next calendar year, me] 40% <- New Year's Resolution

    (Yes, this may seem kind of silly, but bear with me.) This is the requirement drawn out in an operational language. (In this case, I am showing you one example of Planguage.) Now, let me explain the above in natural language:

    WEIGHT is the "tag" or overall statement of requirement. It is given a specific name so as to be useful for searching in a database or referencing in documentation. This tag can be used as the full specifier for the requirement in many documents. When one sees the tag, one knows to look it up in the full requirements specification. It can also help in defect tracking systems when you want to simply apply a given defect or change request to a given requirement. (The tag should also have a number as well.)

    The Meaning is a rough, somewhat informal statement of what the overall requirement means. This can be a definition to make sure everyone agrees with the basics of the requirement.

    The Scale is a definition of the requirement's scale of measure. The idea here is to define the concept, to get a little more clarity and precision to the overall idea.

    The Metric is a definition of how to measure or test the attribute in practice. It is a means of agreeing how the fulfilment of the requirement will be judged in practice.

    The Past is a benchmark of past status for that requirement. It can help to solidify the meaning of terms like "improved" or "better" or "faster" or, in the case of our weight example, "less." (In other words, what is "less" weight? In this case we are saying that last year the system "me" lost 5% of its total weight.)

    The Must is a future requirement target which is necessary for the system in question. These are the minimum levels that a given requirement must satisfy for survival. In our weight example, we are saying a 25% loss of weight is the must. Note that we already know that our past value was 5%. So this time we want a 20% difference from the past value to the must value.

    The Plan is a future requirement target which is necessary for more than just survival. This a level where success and satisfaction come in. ("Survival" levels do not always mean "success" or even "satisfaction" in operational requirements. This is one way that operational requirements are more robust than standard requirements schemes.) In any event, this is a way of understanding the full requirement. This is when you know to stop designing, building, etc.

    Notice that each statement could have several components. For example, the "Plan" is the parameter name (one component), the qualifier is the [End of Next Calendar Year, Me]. The scale is 40%. The source of the scale is, in this case, "New Year's Resolution." Notice that the source of the level is important. For example, in this case it is "New Year's Resolution" and thus, perhaps, not as serious as, say, "military contract." In other words, losing weight because I want to (as a resolution) and losing weight because I have to (to stay in the military) are two totally different sources that convey different weight (no pun intended) to the requirement. (An IT-based example would have a source of "Marketing" or "Business" or "Development" or something along those lines.)

    I could show you a more specific IT-based example, but I hope this one sort of made the point and gave you some ideas. I wanted to present the overall idea without weighing it down (again, no pun intended) with a lot of IT concepts that might have colored your thinking about the concept I was trying to get across. Let me know if I did more harm than good.

    Also: I would be curious to hear from others that have done operational requirements in means other than something like RDM or Planguage. Those are the two that I have used the most and I have not really exposed myself to other methods simply because the aforementioned seem to always do the trick. I would be curious to hear other methods that people have used.

    ------------------

  3. #3
    Points for Confirmed Friends
    Guest

    Re: Operational Requirements

    Hey Jeff. Thanks for responding. I wasn't sure if this belonged with the other thread or not. I've got so many questions I'm not even sure where to start. But I guess the first thing that comes immediately to mind is the use of the qualifiers. I can see that they qualify the basic statements you make but is the qualifier a general concept or does it have to apply in a specific way based on whatever it's applied to?

    Also: is the scale an exact value at all times? And how do you define the scales of measure? Is it a systematic process or one that is more guided by context?

    (By the way, I saw your picture on your site. You don't look like you need to lose weight! Was this just a general example.)

    ------------------

  4. #4
    Senior Member
    Join Date
    Dec 1999
    Location
    Chicago,Illinois,USA
    Posts
    2,537
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Total Downloaded
    0

    Re: Operational Requirements

    <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by AitenB:
    ...the use of the qualifiers. I can see that they qualify the basic statements you make but is the qualifier a general concept or does it have to apply in a specific way based on whatever it's applied to?<HR></BLOCKQUOTE>

    The qualifier(s) distinguish between different required levels at different times, places, and under different conditions. In other words, they are contextual - as requirements should be. The levels can answer to concerns of "when" and "where" and even give some measure of "if." In other words, your requirements can have conditional aspects to them, which is part of being contextual. Most requirements do have this, by proxy, even without operational language but this is a way to make it explicit. What you can see is that you get a sort of dimensional quality to the requirements because the qualifiers allow you to specify requirements in three dimensions of time, space, and "event." Thus, a requirement does not have to be a simple point at one defined time. It can be a curve (if you think about this a little abstractly for a moment) and there can be several dimensions to these curves. Before I lapse into physics-speak of tangent lines to the curve, let me just say that this allows requirements to be stated for both the short-term and the long-term. This also allows you to differentiate requirements for different customer types, users, and even products. It also allows you to state requirements conditional upon certain events or certain conditions being true, such as certain market conditions or certain operating revenue being present or even certain staff being present.

    <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Also: is the scale an exact value at all times?<HR></BLOCKQUOTE>

    Well, the level on the scale that we choose to employ is where we can get really precise about the requirement and thus it can be more or less exact depending not only on the nature of the requirement itself but also on the scale of measure used. Practically speaking, we do not necessarily have to know some exact value (that we call "correct") because phrases such as "greater than 500 page-views per minute", "maintainability ratios at 20% 5%," or "page depths less than three for critical areas" are, in one sense, precise in their meaning, while at the same time not being unnecessarily exact in pointing at a particular level for all times. Keep in mind that the level specification has no intrinsic meaning without also knowing the defined scale of measure and the qualifiers (the extrinsic meaning).

    <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>And how do you define the scales of measure? Is it a systematic process or one that is more guided by context?<HR></BLOCKQUOTE>

    Good question. I suppose it depends. Figure that if we can just apply these ideas to all qualitative requirements we would have a set of relatively clear requirements right from the start. But, as I think you are hinting at, we can still get tripped up by the context or interpretation that we give to the tag itself. Take my previous example. If the word WEIGHT is used, then we will automatically tend to think in terms of measures like pounds or kilograms. Obviously for some concepts we will have immediate cultural scales of measure. For example, in considering bandwidth speed we will often talk about bytes per second or kilobytes per second and that is pretty much cross-cultural. But think about more refined metrics that are not so easily placed into one scale. For example, consider some usability metrics. It is the case in many situations that most of the requirements that will be dealt with on real projects will not be immediately translatable to a given scale of measure, or, at least, to one scale of measure. And even if that were not the case, it is certainly the case that most QA professionals are not trained in strict requirements eliciation and thus the idea of developing scales of measure is not always even thought of, much less adhered to. This is, incidentally, why most requirements are not quantified.

    In these cases, it is often the point where the excuses come in. You will hear things like, "Well, that requirement is more qualitative in nature" or "That aspect is not something that can be measured." Nine times out of ten those statements are an excuse or a falsity, respectively. When statements like this are issued it usually means that we are having trouble getting conceptual control over the concepts themselves in terms of thinking of them as discrete units. Consider concepts like "easy to maintain," "portable", "highly-secure", "user-friendly", "Web-safe", "accessible", etc. There is always a way to quantify those concepts even though many people will tell you they are not quantifiable. That is what the whole notion of the levels are about. We need to apply levels to each of the concepts we bring to a product and then determine what are acceptable levels and what are unacceptable levels. Part of that will be determined by cost alone and by general function but others will be determined by the sometimes nebulous word "quality."

    The point, you ask?

    Simply that we have to have some way to express how much benefit or lack of benefit the different degrees of levels as applied to a concept can cause.

    Consider a few IT-based examples. If you are told that something should be "secure" then you can define one scale such that it indicates the percentage of a defined class of hack attacks which would fail to penetrate the system as compared to those that would penetrate (and thus compromise) the system. Or consider the requirement that a system should be "adaptable." In this case your scale might be a measure of the time or effort (or both) needed to adapt a given system (or subsystems within it) to new requirements of different categories.

    Now, as far as finding a given scale of measure, you can take a few things as a given in trying to do this. The first thing, of course, would be to use common sense to figure something out. Usually a little thought applied to the concept in question will at least give you some idea of how to quantify the concept. However, what if you cannot? Say, for example, that the concept is very complex in its basic nature and there really is no scale that seems to cover what needs to be indicated about the concept. In that case, you might consider breaking down the concept into smaller concepts until such a level of detail can be derived. (This is similar to how developers will often break down a given area of functionality into smaller functions to reach that ideal of one general action for each function.) Also consider using generic scales (perhaps that are used in industry or from other projects) and then use qualifiers, like I showed in my weight example, to get more targeted scales. For example, one method for making scale definitions more easily reusable is to define them generically and then let the necessary detail fall out somewhere else. That "somewhere else" might be the targets that I mentioned: Plan and Must.

    <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>(By the way, I saw your picture on your site. You don't look like you need to lose weight! Was this just a general example.)
    <HR></BLOCKQUOTE>

    Yes. In fact, this example is partially lifted from Tom Gilb who used to present his manufacturing-based planguage in terms of things like buying cars, paying off mortgages, saving money, shedding the pounds, etc. He tried to take everyday concepts to give people the overall idea and I do the same thing.

    ------------------

  5. #5
    Points for Confirmed Friends
    Guest

    Re: Operational Requirements

    <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by JeffNyman:
    He tried to take everyday concepts to give people the overall idea and I do the same thing.<HR></BLOCKQUOTE>

    Okay. Can you give me an example that is IT-based or at least work with me in figuring one out? I'm thinking maintainability. We've got that as a requirement for our system and we measure it not so much by how easy the system is to add to but rather by how easy it is to fix defects in the system, particularly those that are more widespread in their effects than others. So how could I break this down into the operational context that you're talking about?

    ------------------

  6. #6
    Senior Member
    Join Date
    Dec 1999
    Location
    Chicago,Illinois,USA
    Posts
    2,537
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Total Downloaded
    0

    Re: Operational Requirements

    <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by AitenB:
    I'm thinking maintainability. We've got that as a requirement for our system and we measure it not so much by how easy the system is to add to but rather by how easy it is to fix defects in the system, particularly those that are more widespread in their effects than others. So how could I break this down into the operational context that you're talking about?<HR></BLOCKQUOTE>

    Well, I can give you a general idea of something like maintainability in the same sense that I wrote above. I will skip a lot of the discussion:

    MAINTAINABILITLY
    Scale: the proper time for:
    [1] a defined class of faults
    [2] a defined starting point [Default: first knowledge of the defect]
    [3] a defined completion point or the point where it is in fact correctly fixed, without any negative side effects and this is verified.
    [4] a defined resolution process.
    Past: [P1, P2] Average 24 hours <- Inspection statistics
    Plan:
    [P1: {&lt;Requirements faults&gt;, detection logging in inspections, approved in inspection follow up process, fixed in master specification, requirements author}]
    [P2: {first release to field trial} 10% of Past.]
    Must: [P1, &lt;First General Product Release&gt;] 1% of Past <- Management

    &lt;Requirements Faults&gt;: Any requirement specification judged by inspection processes as a major defect, which might cause high downstream costs to correct the adverse effects of.

    &lt;First General Product Release&gt;: The date of access to our product by the general public.

    Hopefully this example, upon further study, will start giving ideas. This is another example based on Planguage as that is what I tend to use. (By the way, I should note that Planguage was originally moved to the software world to allow a certain degree of compliance with CMM Level 4. Not sure if that is relevant to you or not, but this is not just some pie-in-the-sky idea.)

    A few things that you might take note of: First of all, this scale is pretty generic to say the least, however it does have some "defaults" that are at least reasonable in this context. Secondly, notice that there are five generic parameters which can be used to further define the meaning of the scale. These five parameters can be specified in the targets (Must, Plan) and the benchmarks/metrics (Past).

    Consider that a useful set of these parameters can be defined once, like in "P1" and reused to simplify and clarify (as well as indicating that the same set is intended). Also consider that names or labels can be applied not only to the overall requirement but to any useful sub-component of the definition (such as the parameters "P1" and "P2") and then those sub-components can be referred to in a similar fashion as the overall requirement. (That is a truism of operational requirements.) I have purposely not covered many of the details of the above operational format because I want you to look at this and consider it in relation to your own environment. You can also try to figure out, to a certain extent, what I was doing with the above example and perhaps apply that to your own notion of "maintainability."

    [This message has been edited by JeffNyman (edited 01-04-2002).]

  7. #7
    Points for Confirmed Friends
    Guest

    Re: Operational Requirements

    Okay - so take another example. I work in a company that has to change markets sometimes, or at least cater to different ones based on need. So one of our requirements for a two-tier product line is flexibility and we essentially define that as our ability to change products (such as third-party vendors) and markets and to do so easily, with minimal dislocation to the business. And if we're lacking, we want to improve that ability to be flexible. So in this scheme you've given me, my tag is obviously "flexibility." My meaning is then "the ease and ability to change products and markets."

    But I'm having trouble applying this in terms of the scale, plan, must that you keep talking about in terms of the operational language.

    ------------------

  8. #8
    Senior Member
    Join Date
    Dec 1999
    Location
    Chicago,Illinois,USA
    Posts
    2,537
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Total Downloaded
    0

    Re: Operational Requirements

    <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by AitenB:
    So one of our requirements for a two-tier product line is flexibility and we essentially define that as our ability to change products (such as third-party vendors) and markets and to do so easily, with minimal dislocation to the business.<HR></BLOCKQUOTE>

    Okay, so your overall requirement tag might be FLEXIBILITY. Now you come up with an approximation of what people think this means.

    <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>And if we're lacking, we want to improve that ability to be flexible. So in this scheme you've given me, my tag is obviously "flexibility." My meaning is then "the ease and ability to change products and markets."<HR></BLOCKQUOTE>

    Okay, that is good. And keep in mind that the meaning here is what you mean by "improve" in a statement like "we want to improve flexibility." Also note that you are not defining the requirement - you are simply restating it. It is important not to necessarily equate the meaning with the definition. That goes against the grain of natural language but you, as you stated, are working with operational language - a different sort of beast altogether.

    <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>But I'm having trouble applying this in terms of the scale, plan, must that you keep talking about in terms of the operational language.<HR></BLOCKQUOTE>

    Well, you are off to a good start. What you have to do now is check if the basic concept behind the meaning is in some clear fashion a matter of "degrees" of what you (and your organization) consider "good." In other words, ask yourself this:

    Can we describe it by terms such as "better", "equal to", "increase", "reduce" (and so forth)?

    If it is the case that you can do this (and it may not always be the case) you can make a better definition by finding a scale of measure to define it or possibly even having multiple measuring scales as I indicated in the previous post. Once you have a scale you can define numeric points on that scale to represent the current level of something (in this case, flexibility) and the desired future level. I have no idea how strict you all consider flexibililty in terms of metrics so allow me to extrapolate in a hopefully relevant fashion - that of cost. Consider:

    FLEXIBILITY
    Meaning: the ease and ability to change products and markets.
    Scale: cost in % of annual profit needed to develop new products or markets
    Past: {last year} 4% &lt;- current level
    Plan: {next year} 3% &lt;- future desire

    Notice I used your meaning. Then I gave some sources (current level and future desire) and applied a scale of measure to a given metric. The key here is that you do not necessarily have to worry about exact truth (meaning correspondence with reality). There is probably going to be some uncertainty, particularly initially, but the idea is to start making the idea clearer. Eventually, as you have more historical data to fall back on or customer data upon which to rely, you can reduce the uncertainty level quite a bit.

    Also, consider that Scale, Past, and Plan are parameters which can help you define attributes of your scale or of anything else that is relevant. So now let us take another look at the same concept but written a little differently (and changing your meaning a little bit:

    FLEXIBILITY
    Meaning: to improve the ability of the organization to rapidly respond to changing market opportunities and competitive conditions.
    Scale: relative &lt;speed of response&gt; to market opportunities and competitive conditions, compared to our major competitors. 1 = same, 2 = twice as fast, 0.5 = half as fast.
    Plan: {end next year} 2 &lt;- Board Directive
    Past: {last year} *0.7* &lt;- Marketing Estimate

    Speed of Response: Defined as "calendar time from first in-house knowledge of opportunity until a response is defined and ready for approval."

    Now, I am introducing some nomenclature here (that is difficult because UBB really insists on interpreting all my characters!) However, notice that the term in brackets, &lt; &gt;, is defined later on. Thus angle brackets can be used to define terms. Also, by this, we see the Plan matches up with a value on the Scale, which indicates, in this case, the degree of FLEXIBILITY desired - 2.

    We also gave a qualifier to the Plan in {end next year} to indicate when the degree of FLEXIBILITY is desired as well as a second qualifier to indicate where the degree of FLEXIBILITY is desired. We also indicated a source for the plan via the source arrow, given by &lt;-.

    Further, we have a Past parameter indicating what the plan level is in comparison to. In this case we also have a source and we realize that the source is just a guess or a fuzzy value, indicated by the asterisks. (Again - this is just a type of nomenclature. You could indicate this any way you want in an actual document.)

    So what does the above tell us about your requirement to be competitive, at least in terms of being flexible? Well, the Scale defines the market need better. The Past defines the competition (in this case the competition is how good you were last year). The Plan defines your competitive response. The qualifier(s) says when you will respond and in which market or competition area. The Plan level defines how competitive you want to be, in other words.

    The key to realize here is that there are certain standards you can use for an operatinal language, such as various parameters. There are also standard nomenclatures that you can establish to make it clear at a glance. Notice also how this gives very compact requirements that are easily modifiable but also not how amenable this type of language structure could be to a tool that allows you to read in requirements. Finally, notice that this forces a degree of quantification on the requirements - even if the quantification is a guesstimate or a "hoped for" value. That means this type of requirements gathering process is very amenable to metric gathering.

    ------------------

  9. #9
    Points for Confirmed Friends
    Guest

    Re: Operational Requirements

    Okay, Jeff, I gotta tell you: this was getting a little too complicated for me so I was thinking: this might not be for me. But I showed some of your comments to my boss --- and he LOVES it. So now I've got no choice.

    Gee, thanks a lot!!!

    I'm kidding of course but I do need to setup an operational language which I'm going to be doing over the next week here. Are there any standard guidelines that such a language must follow?

    ------------------

  10. #10
    Senior Member
    Join Date
    Dec 1999
    Location
    Chicago,Illinois,USA
    Posts
    2,537
    Post Thanks / Like
    Mentioned
    0 Post(s)
    Tagged
    1 Thread(s)
    Total Downloaded
    0

    Re: Operational Requirements

    <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by AitenB:
    Are there any standard guidelines that such a language must follow?<HR></BLOCKQUOTE>

    Sure. Some of the standard guidelines for an operational language:

    The language should be logically sound. This means it should contain no ambiguities in its internal structure. This means no part(s) of the language should actively contradict other parts or be vague in terms of the formal operational language itself. In other words, no two parts should be capable of being interpreted in exactly the same way. All should be quite distinct.

    Simplicity of description. It should be possible to describe the entire formal language in a simple way. You can sort of see how the examples I was giving you can be described quite simply once you decide on a nomenclature you wish to follow and agree on the terms you will use, such as Plan, Must, Meaning, etc.

    The language should be maximally expressive. This means that the language should have enough entities (qualifiers, parameters, tags, etc.) to fully specify the construction of real-world systems. (Think of how HTML was expressive enough for Web pages - but also think of how it was not expressive enough, because it needed something like CSS to really make it a true markup-type language. Think also of UML's ability to express real-world systems - but also think of its limitations in recognizing different types of modeled approaches to systems.)

    The language should be "feedback consistent." Technically this could fall under being logically sound and if you do it that way, fine, but just consider that consistency here means that it is possible to determine if the system being described conforms to the operational language. If not, there is the potential for disconnect between what is being described and how it is being described.

    And, like most things in QA-related circles, the language should be verifiable - which ties into the one I just mentioned about consistency. In other words, formal verification procedures should be possible within the context of the language itself.

    ------------------

 

 

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Search Engine Optimisation provided by DragonByte SEO v2.0.36 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Resources saved on this page: MySQL 12.50%
vBulletin Optimisation provided by vB Optimise v2.6.4 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
User Alert System provided by Advanced User Tagging v3.2.8 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
vBNominate (Lite) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Feedback Buttons provided by Advanced Post Thanks / Like (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Username Changing provided by Username Change (Free) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
BetaSoft Inc.
Digital Point modules: Sphinx-based search
All times are GMT -8. The time now is 04:50 PM.

Copyright BetaSoft Inc.